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.
Just want to post links to two cool tools that I’ve come upon:
The first is BCWipe which allows you to securly delete files, or entire drives. I haven’t used it, but I’ve talked to someone who has and they say it’s pretty cool.
The second tool is Daemon Tools. This is a nice utility that allows you to mount ISO images as drives in Windows. I’ve got an ISO mounted right now, took a few seconds to click the icon in the tray, select my ISO image and then navigate to to my new “F” drive. Pretty slick.
It was pretty good. Basically what I expected it to be, which was an overview of the new features available in Visual Studio 2005. One of the biggest advancements seems to be better data access, and more flexibility with how data is presented and bound to controls.
The DataSource wizard has been expanded too. You can now specify an external URL to fetch an XML file for a datasource, that was pretty neat. I’m not sure, but it also seemed that all the “auto-generated” connection strings were maintained in the web.config file auto-magically, even though the presenter was generating a new datasource on each page. There’s also a way to specify a stored procedure to use as the datasource. If this option is chosen, Visual Studio will read the parameters required and prompt you for where to get them (querystring, control, object, etc). Also pretty cool.
The other major feature is something called master pages which lets you specify a template-file for the entire site and control the layout with that file instead of having to keep track of includes all over the place. There’s also “skin” support that lets you define how each control should appear (i.e. all calendar controls should have a grey background, 12 pixel font, etc…). Unfortunately, the skin support doesn’t extend to regular HTML controls, so you can’t use it for things like an H1 tag…I don’t understand why not. This means that CSS is still required for these.
It will also validate the HTML for a particular browser, and will do it for section 508 compatibility if that’s required.
They didn’t cover much about Team System, which I was interested in, but they did give us a DVD of Team Foundation Server that we can install to check out the new features. They also gave us a DVD with all the presentation details on it, you are welcome to borrow mine if you want.
I think I never learned how to spell “visible” until I started programming. I probably always spelled it “visable.” Now, after setting the “visible” property of so many controls I’ve become pretty good at typing out “visible”.
Just thought I’d mention that. lol