The duck says “What are you looking at?”
When managing permissions for an ASP.NET application, make sure to set the permissions for the user that the application will be running under. This account is different depending on what version of IIS is running (which you can likely extend to the operating system in use).
To find the user that the application runs under, insert the following code into a page of your application:
The user that Windows XP uses (in my tests) is: ASPNET
The user that Windows Server 2003 uses (also in my tests) is: NETWORK SERVICE
Another factor to consider is that the above accounts were found with the application running with “IMPERSONATE IDENTITY” = False. If it were set to true, the account would either be IUSER_MACHINENAME or the domain user if IIS has authenticated them.
Keep these issues in mind if you need to allow the end users elevated permissions (such as uploading files). You will have to give permissions to different accounts depending on what version of IIS you are using.
Needed a new picture so I posted this one that I took tonight. We’ve got one of our first fires going of the year, and it signals the beginning of fall and winter….and snow soon!!
I originally started taking pictures of the fireplace itself, but then thought that maybe looking at the firer through the glass would be more interesting.
Have you ever cracked an egg into a pan, looked inside, saw a brown thing or some white thing and said “I’m going to pretend I didn’t see that.”
A while ago we started using Microsoft’s Visual SourceSafe at work with Visual Studio .NET 2003. One of the first things we realized when we began working with it was that the reporting capabilities were lacking to say the least. Another problem we faced was the ability to tie together changes in SourceSafe with issues in our issue tracker. By using the free tool VssReporter to find the files that changed since a label or date, we were able to accomplish both of these goals.
The only drawback about VSS Reporter is that the generated files aren’t very pretty. Fortunatly one of the output options is XML which we can make to look pretty using XSLT and CSS. And then, as long as we’re in there, let’s add some functionality to integrate a home-grown issue tracker with changes made in SourceSafe. Then we can answer the question, “What bug or feature required that this file be changed?”
The XSLT file essentially builds an HTML page out of a supplied XML file. It was a little tedious to get working a first, but after a little bit of trial and error I was able to get the layout I wanted.
Another thing that the XSL does it to look for an occurence of “ID=” in the comment field. When files are checked into SourceSafe, we have to make sure that we use a comment that includes this string. Without it there will be no way to correspond changes made to files with the issues submitted in the issue tracker. This part is optioal to you, in fact if you don’t have “ID=” in your comment, the XSL will just ignore it and not try to build a link to the issue tracker. This brings up the first modification you have to make.
If you want to use the functionality to integrate your issue tracking system with SourceSafe, you’ll have to use a comment like the one I describe above. In addition, you’ll have to change the line in the XSL file that builds the link to the issue tracker, since I’m going to guess that your URL to your issue tracker is not the same as the one I made up for the example.
Look for the line that looks like:
and replace it with the URL to your own issue tracker. The comment itself is appended to the end of whatever you specify here, so keep that in mind. Either your issue tracker will have to be smart enough to extract the identifier for the issue from the comment….or you’ll have to get fancier with the XSL to have it pass in only the ID number of the issue. Since my VB.NET skills are much better than my XSL, I chose to make the IssueTracker page the smart one. 🙂
The CSS file is nothing special, it just makes the display a little easier to look at.
The Final Product
An example VSS Reporter XML file shows how the three files work together to produce something that both looks nice (I think), and is useful.
If you look at the source for the XML file, you will see a line at the top that is not included in the XML file that is originally generated from VssReporter. This is a line that tell the XML processor where to find a XSL document to use (I hope I’m not lying about what is going on). In any case, you’ll need to add this line to the top of the XML file.
There’s also a ZIP file that contains the three files mentioned in this article. Just unzip all theee to the same directory.
Hopefully someone will find this useful. VssReporter is a really powerful (and free!) tool. I think Visual Studio 2005 Team System might make this unnecesarry in the future, but probably not for a while.