Tuesday, June 24, 2008
MSBuild Extras (MSBee) - Who should use it?
1. MSBee is a command line utility: MSBee can only be used from the command line, NOT from within Visual Studio 2005, unless you write a Visual Studio Macro to automate it from within the VS Development environment. But even then it will still remain a command line utility with all the limitations of such type utilities.
2. No Support for Partial Classes: As part of the process to use MSBee you have to convert the VS 2003 project to a VS 2005 project using automated converters. During this process, any web references in the VS 2003 application are converted to use the VS 2005 format of web references, which uses Partial Classes. Any code in Visual Studio that uses Partial Classes will generate an error when run through MSBee. In addition any NEW Windows Form created in Visual Studio 2005 will use Partial Classes and Generics, neither of which are supported in .NET 1.1.
3. MSBee is not ideal for multi-project solutions: MSBee can only compile one project at a time. This means that if you have a solution that has 50 sub-projects in it, you will have to compile them one by one!
4. No support for any bugs, questions or issues: The MSBee project discussion page which can be found HERE seems very much dead! You may post a question on their forum and not get a reply back to it EVER! I personally have also tried posting questions on several very active forums such as MSDN MSBuild forum with no response what so ever! Usually this means that the technology is pretty much dead!
5. MSBee does NOT produce .NET 1.1 CAB Files: So if you use CAB files to distribute your DLL with your application you are out of luck!
6. No way to step through the MSBee compiled code: When you generate .NET 1.1 assembly using MSBee, if you encounter Errors and Warnings, there is no way for you to step through the code using Visual Studio 2005! This makes debugging complex errors close to impossible.
So based on the above issues and the 2 week long testing that I performed analyzing this utility, I would recommend that developers should only use MSBee on either a few individual libraries in your VS 2005 solution that are not yet ready for your conversion during a transition phase OR a very simple Windows Form application that doesn't have many sub-projects and does not require constant changing. The technology however is not reliable enough for a Complex Enterprise Level Solution.
Pete Soheil
DigiOz Multimedia
http://www.digioz.com/
Sunday, June 1, 2008
Supporting Multiple Versions of the Framework with one application
- Design-Time breaking changes: These are changes that would only effect you, if you for example have a 1.0 or 1.1 application, and you convert and try to run the application in Visual Studio 2005, with .NET 2.0. If you don't convert or re-compile your lower framework edition application, these changes are not an issue.
- Runtime breaking changes: These are the breaking changes that can impact your application in a big way, if you are planning to support multiple versions of the framework with one application.
So what does that mean in plain english you may ask. The idea is the following: Lets say you have an Enterprise Level Application written in .NET 1.0 or 1.1, with which you are currently supporting people running Windows 2000 and XP. Considering that Windows XP is nearing its End of Life (you can no longer buy new machines with Windows XP installed on them very soon), you are probably thinking about making your application compatible with Windows Vista right about now. Your two options are:
- Program and Support multiple versions of your application for different versions of .NET Framework.
- Have only ONE version of your application that targets all 3 versions of the above 3 Frameworks editions.
Up to a few month ago, if someone would have told me that option #2 existed I would have laughed at them, but it is TRUE! Here is how the whole thing plays out.
Do a test conversion of your application's conversion to the higher version of the framework. What this will give you is a FULL list of warnings and errors that would break your application. ALL the code breaking changes can then be fixed in the lower version of the framework! In other words by doing a Pre-Qualification test and fixing the errors in the lower version of the framework, you will prevent those errors from ever happending in the first place. Go back and fix all the warnings and errors that would otherwise break your application. Make sure to fix them in the lowest version of the framework you want to support.
Once the code breaking changes are fixed, all you have to do is to add the following to the "startup" section of your application's "config" file:
<supportedruntime version="v2.0.50727"/>
<supportedruntime version="v1.1.4322"/>
<supportedruntime version="v1.0.3705"/>
If you have any comments or questions in this regard, feel free to contact me. I would love to get some feedback on this issue, or any other programming related issues you come across.
Pete Soheil
DigiOz Multimedia
http://www.digioz.com/