Moving from VS2005 to VS2008

This is actually really easy as long as every developer on your project makes the move simultaneously. If not, well, there are a couple of things to keep in mind.

  • VS2008 will convert your solution and project files even when you stay in .Net 2.0. Converted solution files can not be opened by VS2005. Project files can still be opened (you’ll get a warning but that is all). This means you’ll have to work with two versions of your .sln files, one for VS2008 and one for VS2005.

  • If you’ve used Microsoft’s Test Project template for writing unit test etc, the reference to ”Microsoft.VisualStudio.QualityTools.UnitTestFramework” will have changed in the conversion, breaking the project for VS2005. This reference will have to be manually changed back and forth depending on what VS version developers use.

That’s it so far, but I’m sure there are some other pitfalls out there waiting for me 😛

Bleeding colors

It is almost two years since I encountered this problem but since I have still not found any good explanations I’ll just make a post about it myself and hope those who could use this info find their way in here.
Problem:
.Net web-applikation using nested html tables which in turn uses stylesheets to set background color, font, font-size and so on. For some unknown reason the background color bleed outward/inward.
Fix:
Set the actual html background color attribute to any color you like in all places where your stylesheet setting includes a background color. This stops the colors from bleeding. The stylesheet background color overrides the html attribute so you’ll get the color you want…
Comment:
This might not sound like the perfect solution, but it works. We stumbled across it by accident after trying everything we could think of and everything related we could find on the internet.

Enterprise Library Pitfall

I was recently asked to bugfix an application. The bug was eaasy enough to fix, just add two lines of code, no big deal. In order to build the application I had to install Enterprise Library 3.1 and re-reference a few .dll files in it. Also no big deal, done it before with previous versions of Enterprise Library… but it turns out i stumbled right into a configuration pitfall!

Short version for those who dont want to read Tom Hollander‘s blog about Avoiding configuration pitfalls with incompatible copies of Enterprise Library:
If you install Enterprise Library 3.x a go with all default options/choices, you end up with two sets of .dll files. If you have to re-reference these files in a project and use the wrong .dll your code will compile but throws an exception in runtime… referencing the other set of dll files will solve the problem (but might cause new problems as well).

Conversion Issues

Objective:
Get a VS2003 ASP.NET web application project from SourceSafe, migrate to VS2005 and add to TFS source control. All done on a PC running Windows Vista. As VS2003 will not run on Vista opening the solution in VS2003 and disconnect it from source control is not possible… might be possible to do from SourceSafe, but I decided to give it a go and just open it in VS2005 straight away.

Problem:
VS2005 conversion wizard fails to convert the web application. Depending on if I let the .sln file point to localhost or changed the projekt path to “C:\myAppPath\myWeb.vbproj” I get two different errors:

Error 1 (keeping localhost/myWeb/myWeb.vbproj as project path):
Conversion Issues – myWeb.vbproj
Thats it… No clue as to what is wrong.

Error 2 (changing to C:\myPath\myWeb.vbproj as project path):
Conversion Issues – myWeb.vbproj:
Unable to open the Web ‘C:\myPath\myWeb.vbproj’. The Web ‘C:\myPath\myWeb.vbproj’ does not exist.
Looks a bit more helpful, but since the file DOES exist… No, no more helpful than what I got in Error 1.

Solution:
As it turned out there wasn’t really anything wrong with the myWeb.vbproj file. Except that it was write protected… Checking the “make writable” checkbox when getting the code from SourceSafe (or just removing the write protection from the file) made all the difference. VS2005 disconnects the code from SourceSafe source control and converts everything Cool

Now I just need to solve all the compilation errors and the code will be ready to check into our TFS… Looking back, I might have been able to avoid the entire problem by following Microsoft’s instructions for migration. But why learn to swim when it is soooo simple to just jump into the deep end of the pool? Anyway, hope this is helpful to someone else…