Wade Wegner

Having recently purchased a new server, I found myself configuring and setting up the various virtual machines I use for software development.  After I setup my development virtual machine, I moved some of my projects over to the D drive and double-clicked one of the project files.  After the IDE opened up, but before the project loaded, I received the following dialog message:

“The project location is not trusted.  Running the application may result in security exceptions when it attempts to perform actions which require full trust.”

This is something I’ve had to setup and configure many times, but since it’s not something I do every day I had to go look up the command to add my D drive as a group with full trust.  To accomplish this, do the following:

1. Select Start -> All Programs -> Microsoft Visual Studio 2005 -> Visual Studio Tools -> Visual Studio 2005 Command Prompt.  This opens up a command prompt with all the Visual Studio program folders in the PATH (type “path” to see).
2. Type the following command:

caspol -q -machine -addgroup 1 -url file://d:/* FullTrust -name "D Drive"

That’s it.  You have now added the D drive to your .NET runtime security policy with the Full Trust permission set.  You will not receive any security exceptions when running your .NET applications.

If you open up the .NET Framework 2.0 Configuration MMC, and browse to My Computer -> Runtime Security Policy -> Machine -> Code Groups -> All_Code, you will see the “D Drive” code group.

I hope this helps!

If you’ve worked with .NET 2.0 long enough, you’ve probably come across the following error:

The description for Event ID ( 0 ) in Source ( .NET Runtime ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Unable to open shim database version registry key – v2.0.50727.00000.

This behavior is caused because the ASP.NET application needs read/write access to a specific registry key but has only read access.

There is a hotfix available for this error: http://support.microsoft.com/kb/918642

Note the following fine print:

A supported hotfix is now available from Microsoft. But the hotfix is intended only to correct the problem that is described in this article. Apply this hotfix only to systems that are experiencing this specific problem. This hotfix may receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next Visual Studio 2005 service pack that contains this hotfix.

This error is more of an annoyance because it fills up the application log.  It shouldn’t actually affect any of your applications.  If you don’t mind ignoring the error, then just ignore it and wait until the next service pack resolves the problem.

Best of luck!