Peter Johnson's Blog

Migrating from VS 2005 to VS 2008

pjohnson — Wed, 02 Dec 2009 17:03:00 GMT

I recently helped migrate a ton of code from Visual Studio 2005 to 2008, and .NET 2.0 to 3.5. Most of it went very smoothly; it touches every .sln, .csproj, and .Designer.cs file, and puts a bunch of junk in Web.Configs, but rarely encountered errors. One thing I didn't expect was that even for a project running in VS 2008 but targeting .NET Framework 2.0, it will still use the v3.5 C# compiler. As such, it does behave a bit differently than the 2.0 compiler, even when targeting the 2.0 Framework.

One piece of code used an internal custom EventArgs class, that was consumed via a public delegate. This code compiled fine using the 2.0 C# compiler, but the 3.5 compiler threw this error:

error CS0059: Inconsistent accessibility: parameter type 'MyApp.Namespace.MyEventArgs' is less accessible than delegate 'MyApp.Namespace.MyEventHandler'

It's a goofy situation, the error makes perfect sense, and it was easy to correct (I made both internal), but I expected VS 2008 would use the compiler to match whatever the target .NET Framework version was. I wouldn't have expected any compilation errors it didn't have before conversion, not until I changed the targeted Framework version.

Another funny error happened around code analysis. Code analysis ran fine in VS 2005, but in VS 2008, it threw this error (compilation error, not a code analysis warning):

Running Code Analysis...
C:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\FxCopCmd.exe /outputCulture:1033 /out:"bin\Debug\MyApp.Namespace.MyProject.dll.CodeAnalysisLog.xml" /file:"bin\Debug\MyApp.Namespace.MyProject.dll" /directory:"C:\MyStuff\MyApp.Namespace.MyProject\bin\Debug" /directory:"c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727" /directory:"..\..\..\Lib" /rule:"C:\Program Files\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Rules" /ruleid:-Microsoft.Design#CA1012 /ruleid:-Microsoft.Design#CA2210 ... /searchgac /ignoreinvalidtargets /forceoutput /successfile /ignoregeneratedcode /saveMessagesToReport:Active /targetframeworkversion:v2.0 /timeout:120 MSBUILD : error : Invalid settings passed to CodeAnalysis task. See output window for details.
Code Analysis Complete -- 1 error(s), 0 warning(s)
Done building project "MyApp.Namespace.MyProject.csproj" -- FAILED.

I especially like the "See output window for details," which 1. screams of a Visual Studio hack as it is, and 2. doesn't actually give me any more details in this particular case, though Google tells me that other people do get more information in the output window.

I noticed Debug and Release modes both had code analysis enabled (I think switching Framework versions swapped them on me and I accidentally enabled it in Release mode), and Release mode wasn't erroring out but Debug was. I looked at the difference in the csproj file, and in the FxCopCmd.exe calls, and the key seemed to be the /ruleid parameters (bolded), of which there were a ton in Debug but not Release. Presumably this is because I disabled some of the rules in the project properties, so I tried enabling them all. The number of /ruleid params went down, but it still gave the same error. The Code Analysis tab in project properties looked the same between Debug and Release.

Finally I unloaded the project, edited the csproj file (I'm glad I found out how to do this within VS, instead of exiting VS and editing it in Notepad), and removed this line, which was present in the Debug PropertyGroup element but not the Release one:

<CodeAnalysisRules>-Microsoft.Design#CA1012;-Microsoft.Design#CA2210...</CodeAnalysisRules>

Code analysis then ran successfully. I imagine this solution isn't ideal for everyone, if you want to enable/disable particular rules, and it's not ideal for us long-term, but it did allow us to keep code analysis enabled without the build failing.

Windows 7 rocks!

pjohnson — Wed, 02 Dec 2009 00:19:00 GMT

I bought my current PC almost three years ago. I've had my own PC for 15 years or so, and, aside from my first desktop and a laptop I only use when traveling, that was the only time I've bought a whole PC, rather than buying parts and assembling my own (a Frankenputer as former coworkers affectionately referred to them). Like many of my colleagues who work in Microsoft technologies, I looked into buying a Dell, and they had a fine deal, and more importantly, they had finally started selling AMD processors, which I can proudly say without qualification is the only CPU in any computer I've owned. I configured one with a dual core, 64-bit processor, and all sorts of new technologies I'd never heard of but were (and appear to still be) the latest and the greatest. ("What's SATA? We use PCI for video again?" I asked myself.)

Windows Vista had RTM'd and was weeks from retail availability, and my PC included a deal to upgrade once Microsoft let Dell send upgrade discs. My PC had a rather small (160 GB, I think) hard drive, which I intended to replace with a 500 GB or so once Vista came out, installing it there fresh instead of trying to upgrade Windows--Windows upgrades have never worked so well for me, whereas fresh installs are fine. Then I heard all the complaining about Vista, and decided to hold off. I ran low on space before Vista SP1 came out, so got that second hard drive anyway and kept my photos there. From then on, Windows XP Professional worked "well enough" so I stuck with it.

Things got bad a couple months before Windows 7 came out. First, Norton AntiVirus misbehaved. To be fair, the program was about 6-7 years old; I kept it around because it seemed to work well enough, I got it free as a student, and virus definition upgrades were free. Then I noticed the dates on the definitions went from a few days ago, to the middle of 1999. It still changed every week, and still found upgrades, so I'm guessing it was just a bug in how it displayed the definitions date, but still made me nervous, as did the prospect of uninstalling old and installing new virus scanners.

Roxio was the next to act up. After Microsoft paved the way with Windows Update, suddenly every software manufacturer was convinced their product was just as important to check at least every week for updates, and the updates, just as urgent. Eventually I got Apple to quit bugging me to install Bonjour and Safari, but I couldn't get Roxio (or, perhaps more accurately, InstallShield Update Manager which came with Roxio) to quit prompting me to check for updates on the 0 products I had told it to check. I googled and finally found a tool I could use to uninstall that piece of it, without uninstalling Roxio, on InstallShield's support site.

That was a mistake. It stopped prompting me, but added about 3 minutes from when Windows comes up after I start my PC, until my computer was usable, and in the meantime, Norton was disabled, Windows Firewall was disabled, and programs wouldn't start. Add to this a nagging problem where my SD/CompactFlash card reader thinks it's USB 1.x intermittently, and the ugly way Windows Search was grafted onto Windows XP, and the fact that XP (and earlier versions of Windows--not sure about 7 yet) just slows down after a couple years, and I knew it was time to upgrade once Windows 7 came out.

The more I learned about Windows 7 (and, to be fair, much of it was new in Vista and largely unchanged in 7, but I'd barely ever used Vista), the more I liked it. The way search worked much faster, more efficiently, and was integrated into everything, even the Start Menu (no more reorganizing each program's 20 or so icons so I could find the ones I actually wanted! no more sorting alphabetically every time I install a new program!)... An overhauled Windows Explorer including a new Libraries feature (not in Vista) that didn't force you to keep everything in your profile for Windows to like it... and finally getting to install 4 GB of memory and take advantage of my 64-bit processor!

After Microsoft decided one day the long-activated Windows XP installation on my laptop was no longer valid, with no explanation why, I wasn't going to chance them deciding the same thing on my main PC, so I broke down and got the full version of Windows 7. I opted for Home Premium after finding little difference between Home Premium and Professional that I cared about, since Home Premium should be able to run IIS, and if it can't, Visual Studio 2008's web server should be enough for what I need on this PC. I installed it not quite a month ago, replacing NAV and Ad-Aware with the new free and highly-rated Microsoft Security Essentials, and Roxio with--well, either what's built into Windows 7 or my favorite CD ripper Easy CD-DA Extractor, and it's great. I can work the way I want to, customize things as much as I need (you're close, iPhone, but not quite there), and boy is Aero pretty. I'm a sucker for eye candy (I do have an iPhone).

The search works great. I was leery about using Windows Search (installed against your will by Office 2007) or Google Desktop Search (must be unchecked in order to not install with every Adobe program and tons of others) add-ons for Windows XP; that sort of thing just seems like too core a functionality to get some freebie add-on to handle. Windows XP's built-in search might suck, but it usually found what I wanted, and didn't take too long. Sure enough, Windows 7 search works instantly, and if you copy over a ton of files it hasn't indexed, as I did when I wiped my hard drive to install 7 then copied back from my backup, it might not find everything right away, but it will after it spends a few minutes indexing them. And, as advertised, it doesn't slow me down while I'm using the PC; I haven't heard my hard drive crank once while I've been writing this long post. By default, it only indexes in your Libraries, and MS suggests anything you want indexed, you put in a Library. That put me off at first--what if I need to search for a system file or something?--but really, the vast majority of stuff I search for slots fine in either the Documents, Music, or Pictures Libraries. Moving from XP to 7 takes some adjustment, but I gave it a chance, and I'm quite happy with it. And if I do ever need to do a search for a certain DLL, it's easy enough to add folders to the list of what's indexed. I don't even have to dig into Administrative Tools and various Control Panel applets and System Tools folders, wondering where Microsoft has hidden that options screen in this version, thanks to the Start Menu search feature. I just click the Windows key, type "index", and it's the first option:

Just like searching on the web, the content is what matters; its physical location is now much less important. You just type in a word or two and it figures out what you want, no matter where it is.

Another great and long-overdue improvement is the Windows Explorer dialogs for long-running file operations--deleting, copying, moving. It gives you more of the path, and best of all, an accurate estimate of how long it will take, and the rate at which it's copying files! No more operations where it takes 45 seconds for the first part and 23987105 minutes for the last part.

The most annoying thing I've found so far is based on principle, and not any difference I've observed. Occasionally, programs crash. Two that I use often, Mozilla Firefox and IrfanView, have each crashed once. (Amusingly, both when they tried to start up the Apple QuickTime plug-in; I have a few things to say about my iTunes migration experience, but that'll have to wait for another post.) But once is all it takes in Windows 7, before Program Compatibility Assistant (PCA) kicks in and applies some sort of mysterious sanctions to the offender.

Obviously I was curious about what those "settings" it applied were, and how to grant amnesty for first-time offenses. That link has a help article with those exact questions. And the answer? "It depends," and "go to TechNet and teach yourself about group policy," respectively. (In their words, "Adjustments to program compatibility features can be made by using Group Policy. For advanced information on how to use Group Policy, go to the Microsoft website for IT professionals.") Seriously? A little more googling and I found out that you can dig into it, or disable PCA altogether, using Group Policy Editor, which... doesn't come with Home Premium. So it sounds like my only choice is manually editing the registry. I can't even find out what PCA changed about how those programs run; a few articles allude to ominous performance degradations in order to ensure stability. Windows 7 addresses so many things that bugged me about XP and earlier versions; it's a shame they dropped the ball on this one. To be fair, it seems that this is how Vista functioned, and Windows 7 didn't make it worse, but didn't improve it, either.

But, to summarize, I'm thrilled with Windows 7, and with 64-bit computing, though I'm a little surprised more programs aren't 64-bit (Firefox and Flash Player, I'm looking at you). Oh well--we had the same problem switching from 16-bit to 32-bit, but I'm glad enough software and hardware is there, that I can upgrade and work just fine until the rest of it makes it.

TFS deleted files still show up in Source Control Explorer

pjohnson — Wed, 02 Dec 2009 00:02:00 GMT

One problem I've had in Team Foundation Server since Visual Studio 2005 and still in VS 2008 is when items are deleted by someone else, they still show up in Source Control Explorer, with a gray folder with a red X icon, even with "Show deleted items in the Source Control Explorer" unchecked in VS's Options dialog. Sometimes getting latest of the parent clears things up, but other times it doesn't, even with Get Specific Version with both Overwrite boxes checked to force a get. In this case, the only option I've found is to delete my workspace and recreate it, which means checking in everything beforehand, and getting latest of my working branches afterwards. It's a pain, but as specified here and approved by a Microsoft employee, that may be your only option until it's fixed--fingers crossed for VS 2010. (We won't get into the other things for which my fingers have been crossed since I first used TFS in 2005, things that VSS did just fine, such as rollback, check in changes and keep checked out, and search.)

Anyone have any better solutions? Deleting and recreating your workspace seems a bit drastic.

VS 2008 and .NET 3.5 Beta 2 released, with Go Live

pjohnson — Thu, 26 Jul 2007 21:18:00 GMT

It's official! In one of the first of a few dozen posts you'll read about it, Scott Guthrie announces Visual Studio 2008 and the .NET Framework 3.5 Beta 2 have been released.

Microsoft Sandcastle

pjohnson — Tue, 03 Jul 2007 16:27:00 GMT

In working with my company's offshore developers, I was tasked with providing them documentation on a set of class libraries we use in our applications. In the .NET 1.0/1.1 time frame, we used NDoc, which, sadly, passed away last year, to turn the XML comments output by the C# compiler into CHM help files. After a bit of googling and a false start, I discovered Sandcastle, which Microsoft uses to build the .NET Framework documentation itself. I also discovered from the Sandcastle blog that it takes a whole mess of manual steps to use, which appeared daunting at first glance, and, being a programmer, I was looking for an easier (lazier) way.

From the official Sandcastle download page, I found the Sandcastle Wiki, and from there, an NDoc-like, Visual Studio-like GUI for it creatively titled Sandcastle Help File Builder. Setting up a SHFB project and getting the documentation to compile, and then to look/behave almost exactly like I envisioned, was simple at this point.

Overall, I'm pretty impressed how easy it was to discover this and find resources to use it--a lot easier than it used to be to fill a component/tool need that Microsoft claims to address (some of the data access pieces in the Visual InterDev 6.0 time frame come to mind). Really, the hardest part was getting the Google terms right!

Again, you can download Sandcastle here. The latest version is the June 2007 CTP (Community Technology Preview, which you probably already know means it's pre-release), released a couple weeks ago.

HTTP modules - subdirectories and private variables

pjohnson — Fri, 02 Mar 2007 21:29:00 GMT

I recently finished (for now--there's always more to do) one of the more complex HTTP modules I've worked on. I have an application first written in the ASP.NET 1.0 beta 2 time frame that's since been upgraded to 1.0, 1.1, and now 2.0. It had a lot of custom authentication and error handling code in global.asax, and for general architecture and server management purposes, I wanted to move this code into separate HTTP modules. I ran into a couple gotchas I wanted to document.

Lesson 1: You can't disable an HTTP module for a subdirectory. I wanted to remove the HTTP module for one subdirectory using the <location> configuration element, and while it let me put it in my web.config fine and never threw an error a la "It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.", when I ran it, it went into the module's code as if that config section wasn't there.

Scott Guthrie explained to me why: "HttpModules are application specific. When an application starts up, a number of HttpApplication's get configured (one for each logical thread that will execute in the application), and HttpModules are created and assigned to them. That is why you need to configure them at the application root (or higher) level in config. This enables much better pooling of resources." He pointed out that other HTTP modules in ASP.NET handle this with custom configuration sections, which is more work than I was looking at doing for this release.

An exception to this rule is if that subdirectory itself is configured as an IIS application, but in many cases (including mine), this is more trouble than it's worth, limiting what user controls it can see, requiring its own bin directory... and if you're going to do all that, it's probably going to need its own web.config file anyway.

Lesson 2: You shouldn't use private member variables in an HTTP module. I've been an ASP.NET programmer long enough that I thought I could figure out whether member variables were safe or not. I could argue for it either way, and I wasn't feeling ambitious enough to wade through all that code in Reflector. I finally found official documentation for the HttpApplication class that said, "One instance of the HttpApplication class is used to process many requests in its lifetime; however, it can process only one request at a time. Thus, member variables can be used to store per-request data." So it made sense that if an HTTP module is wired to a particular HttpApplication instance, the same rule would apply, and member variables would be safe in HTTP modules as well.

Again, Scott helped me out by advising me against member variables: "If you have an async operation occur during the request, I believe ASP.NET might switch the HttpModule to another thread to execute. That is my worry with storing local variables. It might work in your dev environment, but generate different results under high-load on a server." And no one needs any more "works great in dev and QA but not production" sorts of issues. He advised storing such things in HttpContext.Items instead, but in my case, the data was so cheap to calculate and consumed rarely enough that I decided to just have a method to calculate it every time. Interestingly, by switching from global.asax (where member variables were fine) to an HTTP module, I took a step back in this department, but overall it was the right move and the way I would have written the app from the beginning had I been more familiar and experienced with ASP.NET.

ASPInsiders Summit 2006 - C# 3.0 and LINQ

pjohnson — Tue, 16 Jan 2007 21:19:00 GMT

C# 3.0 (not to be confused with the confusingly-named .NET Framework 3.0, which includes C# 2.0, not C# 3.0) was the most exciting thing discussed at the ASPInsiders Summit. When I first learned a bit about LINQ at the 2005 summit, I didn't really get what was so great about taking some mangled SQL syntax and duct-taping it onto the language. Given a few hours for Anders Hejlsberg, the lead architect of C#, to explain LINQ, how it came to be, how it works behind the scenes, and why it's a Good Thing, I changed my mind. He and Scott Guthrie sold me on LINQ (at least, as much as I could be until it's released and I can play with it first-hand).

Most of the big changes in C# 3.0 were driven by LINQ, which is why I'm talking about them in conjunction. But this doesn't mean they're LINQ-specific; I can think of a ton of cases independent of LINQ where this stuff will be useful. It reminds me of when "XML web services" was repeated in every lecture, article, blog post, knowledge base article, and whitepaper from Microsoft that talked about the .NET Framework when it first came out, as if that was the main thing anyone would use the framework for. Though I've done a ton of .NET programming, I think maybe 1% of has had anything to do with web services. Thankfully, only few seem to have been fooled by that and adoption took off anyway.

But back to C# 3.0's new features. These are explained in more depth and with more examples on the LINQ Project site, so check out the overview there for more information--no need for me to duplicate all that.

Local variable type inference (or, "No, it's OK, the var keyword isn't evil anymore"). Former ASP programmers like me instinctively shudder when we see the keyword "var", and recoil a bit when we hear it's being introduced to C#. But this has nothing to do with late binding or strong typing--this is just something to allow programmers to be just a little lazier. The basic idea is if you have a long type like Dictionary<int, MyCoolButLongType> you're newing up on the right, you don't have to type all that on the left since the compiler already knows what type it is.

int i = 5;
Dictionary<int, Order> orders = new Dictionary<int, Order>();

is 100% equivalent to:

var i = 5;
var orders = new Dictionary<int, Order>();

The variable orders still has the same type of Dictionary<int, Order> it does in the first example. It'll still behave the same as it did, you'll still get the same Visual Studio IntelliSense you did, and the IL will be the same. Var is not variant here--it's "I'm lazy so let the compiler figure it out."

Extension methods. This allows you to "add" your own methods to types you can't otherwise change yourself, e.g. in the .NET Framework or third-party libraries. So if you've always wanted a string.FooBar() method, just write it as an extension method, include its namespace, and you've got your string.FooBar() method. Everyone's got a pet peeve this can address--some method they wish the framework provided, a string or numeric operation. Now it's yours, whatever you want, however you want it to work.

Lambda expressions. This is another feature for laziness/concision, making it easier to write a function inline than you could with C# 2.0's anonymous methods.

List<Customer> customers = GetCustomerList();
List<Customer> locals = customers.FindAll(c => c.State == "KY");

reads as "Find all c such that c.State equals Kentucky". The compiler infers that the return type of this lambda expression is boolean, due to the comparison operator ==.

Object initializers. This is one of the (few) good things about VBA (Visual Basic for Applications), the version of VB included with the Microsoft Office products and a platform on which I unfortunately found myself doing a lot programming several years ago. Using the new keyword to create an instance of an object, you can now specify initial values for public properties and fields.

Person value = new Person { Name = "Chris Smith", Age = 31 };

creates a new Person instance, setting its Person.Name and Person.Age properties.

Query expressions. This is what LINQ looks like on the surface. An example statement using a query expression on the right side:

var customerQuery = from c in customers
where c.State == "WA"
select new {c.Name, c.Phone};

where customers is a custom collection, like List<Customer>. One of the biggest questions I had is why in the world they took the SQL SELECT..FROM..WHERE syntax we all know and "love" and jumbled it up. Fortunately, Anders addressed this, saying Microsoft considered implementing LINQ syntax it in the same order as SQL, but really, SQL doesn't make sense. When you execute a SQL query, it starts with FROM and WHERE (table/index scans), then goes to SELECT, just like these query expressions in C#. C# doing it this way both helps get IntelliSense and is more forward-looking (what makes sense if we were designing this from scratch, and giving ourselves the option to expand it later) than backward-looking (how's it been done before; what are people used to). It looks weird the first time to those of us used to seeing SQL, but it makes sense after you get past that hump.

Expression trees. The .NET Framework (and C#) will have expression trees and expression parsing built in. So for example, you can give it a string, and it will build a tree of Expression objects behind the scenes to represent it. Anyone who's written their own search or query syntax can imagine how powerful this could be.

So look again at the above query expression. The C# compiler rewrites it as:

var customerQuery = customers.Where(c => c.State == “WA”).Select(c => new {c.Name, c.Phone});

Now you can see how all this begins to tie together: A query expression gets expanded into a more verbose and less readable statement using extension methods (List<Customer> doesn't have a native Where method) and lambda expressions. The lambda expressions get parsed into expression trees and return anonymous types (the return value of the Select lambda expression). We reference the results of the query expression with a local variable using type inference (we can't determine the return type of the query expression, and with type inference it doesn't matter--nevertheless it's still strongly typed). It's the circle of life!

Hopefully I'm explaining this clear enough that some of you can understand why at this point I was getting very impressed. Keep in mind all this compiler magic doesn't come at any efficiency/performance hit at runtime.

In case this syntax isn't enough to sell you on LINQ, here are a few more objective reasons. With just ADO.NET today, you have queries as quoted strings, parameters loosely bound, and results loosely typed, and the compiler can't help check code; LINQ helps in that classes describe data, the query is natural part of the language instead of a string, and the compiler provides IntelliSense and compile-time checking--it's entirely strongly typed in C# and VB. Another reason is that LINQ can be used to query against objects, DataSets, SQL data sources, XML out of the box using an extensible provider-driven model like those you find in .NET 2.0 today. And it has paging built-in, not specific to SQL Server.

Again, check out the LINQ Project Overview if you want more information, including a more detailed look at the features I mentioned and a few I skipped over.

ASPInsiders Summit 2006 - IIS 7

pjohnson — Fri, 29 Dec 2006 18:15:00 GMT

Earlier this month was the ASPInsiders Summit at Microsoft. As finishing the QA cycle for, deploying, and supporting a project at work has kept me busy, followed immediately by the holidays, I haven't had much chance to blog about it until now. This is partly a good thing, since it means others more punctual than me have blogged about it first and saved me some trouble. Thanks, Steve!

As usual, they talked a bit about stuff that's recently been released, such as Visual Studio 2005 Team Edition for Database Professionals and the now-released action-packed VS 2005 SP1, where Web Application Projects becomes a first-class citizen in the Visual Studio world as they should have been since day one.

One of the cooler things from the first day, beginning in Scott Guthrie's opening talk and continuing into its own sessions, was IIS 7. I'm more focused on writing C# code for the web and SQL Server database maintenance than IIS administration lately, but I've been responsible for varying degrees of it since IIS 4. I remember when Gartner published their scathing recommendation that companies ditch IIS until it's rewritten, which as I understand happened soon after with version 6. Still, Scott said IIS 7 is the biggest release of IIS in years (though he may have meant the three and a half years since IIS 6 came out!).

There's a new system.webServer configuration file section for IIS settings, like the system.web settings used for ASP.NET applications today. This puts another nail in the coffin of the horrible, brittle binary metabase from IIS 5 and earlier, moving things like directory browsing and default document settings into a config file, allowing you to set it on the machine level and override it during xcopy deployment per application if you want. And you can make changes programmatically.

IIS 7 also takes another step towards a more modular design, going from about 6 components today to about 42. So you can take things like ISAPI filters, CGI, ASP, ASP.NET, and Windows authentication and enable/disable them as needed for your particular server. Making up for lost time on the security front, this allows administrators to greatly reduce IIS's attack surface. Plus, if you don't like the way IIS does something, you can write your own module in ASP.NET and override it. Scott's example showed the directory list module replaced by one he'd written, that instead of giving you a boring file listing, gives you a thumbnail-based image gallery instead. Cool!

(As a budding photographer, I was impressed by the pictures he used to demonstrate this--close-ups of lions he'd taken with a monster 400mm lens during a recent vacation to South Africa.)

ASP.NET gets one step closer to (if not reaching entirely) full-class citizenship. As Mike Volodarsky explains, whereas requests before had to go through the IIS framework before reaching the ASP.NET framework, the two duplicate layers are now integrated into one. An example of why the old way sucked is how many folks had applications set up to be anonymous in IIS, so it would pass through authentication to ASP.NET which would then authenticate the request. An example of why the new way is cool is that since all the authentication happens at the same level--Basic, Anonymous, Windows, and ASP.NET's Forms Authentication, to name a few--you can now have ASP and PHP apps, as well as static files like JPG and CSS, authenticating via ASP.NET Forms Authentication. Cool. We've got some sites that still have a lot of ASP pages to migrate over, so this could help out a lot.

Oh, and they're getting rid of ISAPI too. As I said, you can write modules in .NET, or in C++ using a new, better API. I'm not a Windows C++ programmer, so you're on your own with that one.

This is all built into Windows Vista as I understand it (having not had much opportunity to dig into Vista yet myself); the upcoming "Longhorn" release of Windows Server will have even more, which unfortunately is under NDA at the moment. As a feature-complete, publicly-available Beta 3 is expected in the first half of 2007, you'll hear about it soon enough.

Windows service setup projects - Unable to build custom action error

pjohnson — Mon, 14 Aug 2006 18:22:00 GMT

I ran into another under-documented snag upgrading my solution to Visual Studio 2005. It has a Windows service used for behind-the-scenes maintenance sorts of tasks that run on a regular basis, and a corresponding setup project. Now, it's also got setup projects for command-line apps and web apps, and all of those upgraded fairly well--it got confused on the output, so I had to delete and re-add the appropriate Primary Output to each project, but after that, all the setup projects built fine, except the Windows service one.

It gave this error in the Output window when I tried to build it.

Building file 'C:\whatever\MyProjectSetup.msi'...
ERROR: Unable to build custom action named 'Primary output from MyProject (Release .NET)' because it references an object that has been removed from the project.
Build process cancelled

In the Error List, when I double-clicked on this error, it took me to the Custom Actions window for this project. As documented in this Microsoft Knowledge Base article, the project had the Primary Output listed as a custom action for all four custom action types--Install, Commit, Rollback, and Uninstall. The Uninstall one is the only one highlighted, though, with a red wavy underline. This told me nothing more about the error.

Sometimes in cases like this, when I open the project file in Notepad, it can make it clear what's wrong. For instance, when a Crystal Reports report loses its corresponding .cs file, I can reassociate them by manually editing the project file and reopening the project. But .vdproj files are different beasts--much uglier and harder to manage in Notepad.

That KB article said it was set up correctly, and yet it wasn't building. So I tried deleting all four custom actions, and re-adding them per the directions in the article, and it built, installed, started and ran, and uninstalled just fine. (For what it's worth, Microsoft did document this process in an MSDN Library article.)

One difference I see is that all my project outputs in all my setup projects, including these custom actions, now read "(Release Any CPU)" instead of "(Release .NET)". I'm not sure what difference that makes, nor why I should care (and have to correct it manually), but as far as I can see, it's working fine now. We'll see if I get any nasty surprises when I give it to QA for testing.

Ambiguous match found

pjohnson — Fri, 11 Aug 2006 17:31:00 GMT

Looks like I've been away a few months. Sorry 'bout that. I've had stuff to write about but not enough time to set aside to do so, which is a little ironic; one of the main reasons I created this blog was so I could take 5 minutes and jot down stuff I find out while developing, largely in case it helps others, not so I could write my usual verbose 5000 word essays (which is what my AspAlliance site is for!).

So, on that note, I wanted to share how I solved a goofy error that made no sense. I was upgrading a good-sized web application from .NET 1.1/Visual Studio 2003 to .NET 2.0/Visual Studio 2005 using Scott Guthrie's well-written instructions and the Web Application Projects add-in. Going through VS2005's automatic conversion and building it was pretty painless when I followed Scott's instructions; one wrinkle I ran into is that it forgot about the three web projects, so I had to add those manually using "Add Existing Project" after I converted the others.

But it built and I went through the app and everything was fine. I didn't do the "Convert to Web Application" command on the whole project, preferring to keep a closer eye on what it changed, and touch it up after. So I started doing it folder by folder per Step 8 inScott's instructions, and it seemed to work great, until I got to one particular page and got this error.

Parser Error
Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.

Parser Error Message: Ambiguous match found.

Source Error:

Line 1: <%@ Control language="c#" Inherits="MyApp.Namespace.MyCoolControl" CodeBehind="MyCoolControl.ascx.cs" AutoEventWireup="false" %>
Line 2: <%@ Import Namespace="MyApp.OtherNamespace" %>
Line 3: <div class="openingParagraph">

Source File: /MyApp/Namespace/MyCoolControl.ascx Line: 1

So it says Line 1, Line 1 is highlighted, and yet, the only reference in line 1 is a fully-qualified one. To be safe, I pulled all my custom assemblies into the invaluable .NET Reflector and double-checked, and there was only one instance of that class name anywhere.

I tried what I normally try when I get weird ASP.NET errors I shouldn't be getting, a process many of you are probably too familiar with if you've worked with ASP.NET very long. I restarted IIS, deleted and recreated the application in IIS Manager, deleted the Temporary ASP.NET Files directory for MyApp (after closing Visual Studio), restarted Visual Studio and rebuilt the project, etc. None of these helped this time.

Scott's instructions mentioned this error in some cases, notably the IE WebControls, but the solution has been to specify the full namespace, not just the class name, so that didn't help me. Other Google search results were similarly unhelpful, until I found the blog of a guy named Eran Sandler who talked about his "Ambiguous match found" error and how he solved it--two protected fields with names that differed only in case, apparently confusing reflection.

Sure enough, my code had the same problem--I had myRepeaterControl (name changed to protect the innocent, of course), and MyRepeaterControl in my code-behind. The latter wasn't used and was probably left in mistakenly; I removed it, it still built fine, and the control worked great.

Thanks, Eran!

Convert.ChangeType wrapper that handles nullable types

pjohnson — Fri, 19 May 2006 17:06:00 GMT

As I mentioned before, the Convert.ChangeType method doesn't handle nullables. One of the comments proposed a replacement, but I preferred to have a wrapper around the original Convert.ChangeType method, so in general it would behave identical to Convert.ChangeType, except that it would handle nullable types as well instead of throwing an InvalidCastException.

I wrote, compiled, and tested such a wrapper finally, and posted it as a CodeSnip article on ASP Alliance, where I've also been an author for over five years. Check out my ChangeType method, use it, let me know what you think! Oh, and if anyone on the CLR team is reading this post, feel free to incorporate my wrapper in the next .NET Framework service pack. ;-)

Special thanks to a fellow ASP Alliance author, the multiple blog-having J. Ambrose Little and alert reader, Google user, weblogs.asp.net surfer, and my brother, Toby Johnson for helping me put together this method.

Web Application Projects for Visual Studio 2005 released

pjohnson — Tue, 09 May 2006 15:09:00 GMT

Last night, Microsoft released the final version of the Web Application Projects option for Visual Studio 2005. This was one of the first things I blogged about, and they've been hammering it out and going through betas and CTP's and RC's ever since. For now, it's a separate download, but going forward (as of VS2005 SP1) it'll be integrated into the application as a "first-class citizen."

In the .NET 2.0 app I'm working on, I finally got to a point in the project where I could try it out (a full 12 hours before release!). I followed Scott Guthrie's directions to upgrade an existing VS2005 web site (I'm a C# guy; Scott has directions for VB too) and was quite pleased with them overall--easy to follow, didn't leave much out.

First, the things I like about WAP:

- Namespaces: In a VS2005 web site, newly added files don't get a namespace, which is kind of kludgy if you have a VS.NET 2003 project with namespaces specified for every page and control, then upgrade to VS2005, and add new pages and controls and have to leave them in the default namespace, or manually put that code in (or maintain the VS2005 file templates manually). WAP lets you specify and modify default namespaces again.

- AssemblyInfo.cs and generated code files: I'm a pretty picky developer and I like being able to specify properties for my assemblies myself, and see all the code that goes into that assembly, and WAP makes that easier. You see the MyPage.aspx.designer.cs files in VS's Solution Explorer, which contain the wireup code that was mixed in with the regular code-behind file in VS.NET 2003, and generated and compiled behind the scenes in VS2005 web sites.

- Faster compilation: My web app is rather small, but it was still noticeably faster to compile it as a WAP rather than a web site. According to Scott:

VS 2005 WAP build times are significantly faster that Web Site Projects – in some cases 10x or more. That is because WAP projects only compile the code-behind of the project and standalone classes (like VS 2003 did). Web Site Projects do deeper compilation and verification, which is nice, but which does slow things down. There are several settings you can change to modify this, but WAP projects will always compile fastest.

Note that I'm only talking about building the project in VS, not the JIT compilation from MSIL to native code that happens when you first pull it up in the web browser; that speed didn't appear to change in my case.

Here are a few snags or "opportunities for improvement" (to use a more overly politically correct term) I found in upgrading from a VS2005 web site to a web application project:

- One thing Scott did seem to leave out of his directions is how to convert web references. I had to dig out an URL, have VS2005 recreate the web reference, and then make some manual changes (since Reference.cs is apparently dynamically generated with a web site project, so I couldn't use it for, um, reference). Unfortunately, this is the way to do it for now (which would be a real pain if you listened to Microsoft's marketing a few years ago and used web services for darn near everything!), though they're considering automating that conversion in future versions.

- Another thing the directions don't take into account is source control. I don't know if it's not expected that a large enough portion of the audience will be using source control to warrant including that in the directions, or because they're keeping it simple. As it is, I didn't want to lose my files' history (and didn't want to mess with branching, especially since I'm using the source control in Team Foundation Server), so I moved from the site to the project instead of copying, and crossed my fingers I didn't break anything. So far, so good--the site's working great on my development machine.

- Having upgraded my application from VS.NET 2003 originally, I had a Global.ascx and Global.ascx.cs; I moved the latter to App_Code and manually changed the former to inherit from it. So I manually moved that back when moving it to a web app project. I'm not sure if that's a common practice that would be worth including in the instructions, or just the weird way I did it when moving from VS.NET 2003 -> VS2005 web site. Also, when I double-click on Global.ascx in VS2005, it refuses to open that file, opening Global.ascx.cs instead. To change Global.ascx, I had to open it in Notepad (*gasp*).

- We have a third-party component (Aspose.Excel, now called Aspose.Cells) that uses a .lic licensing file. I'm not sure we've ever (in VS.NET 2003, VS2005 web site, VS2005 web app) handled this the "right" way--pretty much just get it working and then leave it alone. I got it working this time by copying the file from the web site project's bin to the web app project's bin via Windows Explorer. I was hoping there would be a best practices way (probably using VS2005) to get this .lic file copied to the bin directory; I looked on the component reference's properties and didn't see anything obvious. No such luck for the time being.

Overall I'm happy with it, and would definitely use a web application project for a new VS2005 project over the web site model. I'm kind of a low-level, class library developer sort of guy, so it's nice to have namespaces, AssemblyInfo.cs, generated code files in the solution, faster compilation, etc. back.

Do you need to turn off your PC at night?

pjohnson — Wed, 26 Apr 2006 19:26:00 GMT

I knew there was a reason I still subscribe to the Microsoft At Home and At Work Newsletter.

This morning's edition linked to an article analyzing your PC's power usage at various states--on, off, hibernate, and standby--both the computer and the monitor. Sure, I knew you save power by turning it off, but I hadn't realized (nor thought about it lately) that turning it off and on every day doesn't really hurt much like it used to when I first started using computers (don't make me say how long ago THAT was). Nor did I realize that CRT's use so much more power than flat panels. The bottom line of the article is that turning your PC off indeed saves more power than the other options, but setting it to hibernate overnight is nearly as good.

It also made a frank point that struck the bleeding-heart tree-hugging hippie in me (not to mention my frugal side)--is it worth wasting that energy (and money) to save a few minutes' startup time (to boot, log in, and restore state, such as opening mail, browser, and chat programs) every morning? And, using Windows' hibernate or standby, you don't even take THAT hit. I think Windows default settings have standby and/or hibernate on, but I always turn it off after I install Windows because of that annoyance, not thinking about the consequences.

Time to turn it back on on my computers.

ApplicationException obsolete?

pjohnson — Wed, 12 Apr 2006 18:09:00 GMT

As I catch up on finding and adding to NewsGator all the blogs I've missed and shouldn't have, I found the FxCop blog thanks to a recent post by Mitch Denny. I'm a nut for best practices, but admit I don't use FxCop itself as much as I should. I just read up on design guidelines and do my best to implement them, which works out quite well relatively, judging by a lot of other code out there.

In skimming said FxCop blog, I found an entry on ApplicationException. It recommends not throwing ApplicationException in your code, nor deriving any custom exceptions from it, instead using Exception. Now, I've written a fair bit of code and a dozen or so custom exception classes that derive from ApplicationException which was the recommendation from Microsoft and the community, so this news was a bit shocking and hard to understand at first. I posted a long comment there with my feedback before realizing that it'd make a good blog post.

These new recommendations coupled with the fact that ApplicationException is by definition not something the Framework will derive/throw, begs the question: What's the ApplicationException class to be used for now? And if the answer is "nothing," why isn't it marked as obsolete, since the recommendation in Brad's entry came out nearly 18 months ahead of .NET 2.0? Edit: David Kean, who cowrote the FxCop entry, replied and let me know a practical reason that class wasn't marked as obsolete (since it's used as a base class, so marking it obsolete would be a breaking change). So I can understand why it wasn't, but it would still be easier on developers if the compiler gave a warning like it does for other classes that should no longer be used in .NET 2.0.

The post references "several outdated documents floating around on the web (some orginally published by Microsoft)" that still advise deriving all your exceptions from ApplicationException. One pretty significant example of said documents is the official Microsoft .NET Framework documentation.

After thinking about it and reading the applicable parts of Brad's entry a couple times, I can now understand the reasons for Microsoft reversing their advice regarding ApplicationException. I just wonder why the FxCop blog and a couple other blogs were the only ones that said so, and not more high-profile sources like the .NET documentation itself.

New ASP.NET and IIS webcasts

pjohnson — Tue, 28 Mar 2006 16:42:00 GMT

I finally found and started using a decent RSS reader, NewsGator (not to be confused with Gator spyware). I'm still ironing out how to use it most efficiently, including figuring out which sites with RSS feeds work best in an RSS reader and which are better for me to just visit, and the best way to group feeds, but for now it's a useful way of keeping on top of the ASP.NET news headlines from all the Microsoft employee bloggers, and those elsewhere in the community with interesting stories from the trenches.

Scott Guthrie recently posted information about upcoming ASP.NET and IIS webcasts, which have their own RSS feed too.

A few in particular:

- Microsoft.com Operations Introduces Real World Debugging: Diagnosing Memory Leaks in ASP.NET Applications (Level 300) - This becomes a topic of interest for me every so often.
- Managing IIS 6.0 Servers in an Enterprise Environment: A Handful of Tips and Tricks (Level 200) - I don't have much responsibility for server administration, but still sounded useful.
- Efficient Deployment and Management of ASP.NET 2.0 Applications on IIS 6.0 (Level 300) - Ditto.