Saturday, April 30, 2005

My local project is not fully trusted by the .NET runtime....ZoneStripper to the rescue

I started working on a DotNetNuke site for a local charity this week. I downloaded the latest build and extracted it to my local hard drive, but when I opened it, I got this error:

The project location is not fully trusted by the .NET runtime. This is usually because it is either a network share or mapped to a network share not on the local machine. If the output path is under the project location, your code will not execute as fully trusted and you may receive unexpected security exceptions.

What? My local hard drive shouldn't be trusted. That's probably true, but how does Microsoft know? If you're running Windows XP SP2 on an NTFS partition it tracks the Zone for all files. Since my DNN files were created on another machine, they're flagged as coming from the Internet Zone (ZoneId=3).

You can view the setting in notepad. Enter this at the command prompt: notepad.exe DotNetNuke.sln:Zone.Identifier. It will display a file stream similar to this:


How do you remove/change this setting? Windows provides an interface to remove this setting in the file properties dialog, but you have to click “Unblock“ for each file. (uhg!).

Luckily there is a free utility named ZoneStripper that will recursively clean all the files in your directory. Check out the readme after downloading the code. It explains what is happening in more detail...if you are interested.

Sunday, April 17, 2005

Web Projects Boycott, Long Live Class Libraries

I try to be a good programmer. I understand that there will be other programmers who will come after me and have to maintain and update my code. I think of these poor souls (you know who you are) when I'm setting up a solution and designing a new system.

One of the simplest things I do is organize my code so that resides in an intuitive folder structure. First I create a Solutions directory, then I add each project under the solution's folder. That is until I try to add a Web Project. By default, the web project is added to the home directory of the Default Web Site in IIS, generally C:\inetpub\wwwroot\. I try to “trick“ VS.NET by creating a virtual directory and pointing it at my project directory, then hack my .webinfo file to get everything to work correctly, but this seems to cause Source Safe to complain when another developer tries to get latest.


The other issue I have with web projects it compiles all the files into one assembly for the entire website. The websites that I develop have multiple teams working on different sections of a website, with each team having it's own release schedule. How does the “admin“ section team release its changes to production, but not release the updated code for the “news“ section team? If they are both working under the same web project the simple answer is, “they don't“. When the project compiles all the code is compiled into one assembly.

Solution (er...Hack)
But then I started to think, how is a web project different than a class library project? Besides specific file types for web development (.aspx, ascx, asmx) and a virutal directory,  they are the same. Even the project type of a web project property says “class library“. Hmmm....

What would happen if I created a class library project, pointed a virtual directory at it, added a web.config file and a .aspx page? Well, it works just like a normal web project. This solved my problem. Each section (folder) of the web project would be in its own class library. I would point the output directory for all the projects to the same \bin directory at the “root“ of my web application. Everything will work this way. The next problem I ran into was that the class library projects don't have the ASP.NET file types in the “Add New Item...“ dialog box, but I found this article that explains how to fix that problem.

The good news is that all of my issues with the web project goes away with VS 2005. Each web page compiles into it's own assembly. However with VS2005, I have some other issues that hopefully I will blog about later...