DigiOz Programming Blog
For those of us who are not yet familiar with this product, MSBuild Extras Toolkit for .NET 1.1 (MSBee for short) is an addition to the Visual Studio 2005 MSBuild compile engine that allows developers to compile .NET 1.1 applications from within Visual Studio 2005. Normally, Visual Studio 2005 is only able to produce .NET 2.0 assembly (3.0 as well if you install the add-on). MSBee is however not fit to be used as the means to generate a multi project enterprise level solution in both 1.1 and 2.0 Framework. Here are some general limitations of this tool:
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/
Jun 24 2008 13:31
Supporting different versions of the .NET Framework has been a much talked about issue for me for as long as the Framework has been around. Especially beginning with the .NET 2.0 Framework, with all the code breaking changes that went along with it. Code breaking changes come in two flavors:
- 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"/>
That's it! Lets say now that you run your application on a Vista Machine which doesn't have .NET 1.0 and 1.1 installed on it by default. Your application will Automatically choose the higher version of the Framework and run using that version of the Framework. Assuming that you have already taken care of all the code breaking changes, you can now support 3 different versions of the Framework at the same time with only 1 Version of your application!
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/
Jun 01 2008 23:01
Not all .NET code are created equal?Wait a minute, I thought the whole point of having a programming framework was to allow code to execute the same way and with ease regardless of the hardware! When I first got a bug report which basically indicated that the same program written in the same version of the .NET Framework executed differently (and produced numerous bugs) my first reaction was "IMPOSSIBLE!". But upon further testing and inspection I confirmed this issue or glitch as I like to call it.
The problem is not exactly that the same routine produces different results, but that due to a set of events firing in a specific order, the outcome of your code may be different on different machines.
Consider the following case. Suppose you have a .NET 1.0 application, that was later upgraded to .NET 1.1 (Visual Studio 2003). Some possible client machine configuration:
1. Having .NET 1.1 ONLY on a machine.This is probably the ideal case for a .NET 1.1 Application. All built in events such as "Change" and "Validate" will fire as needed and everyone will be happy.
2. Having .NET 1.1 AND 2.0 on a machine side by side. In some instances, depending on if the client machine has both .NET 1.1 and 2.0 installed, built in form events "SPECIALLY" Validation routines were found to fire when there was no reason for them to fire (i.e. no data was changed to cause a Validation routine to fire, but a Validation fired on several text boxes and combo boxes while changing tabs in a tab control unrelated to either of the two!
The closest thing to an answer that I was able to find to this issue was that even though your application was written to use .NET 1.1, the .NET CLR still chooses the CLR of the higher version of .NET for some Windows Form related events. It just so happens that the developers who wrote this application also had both .NET 1.1 and 2.0 installed on their machine, as well as the QA staff that QA Tested the application. When the application was deployed to the field, several user machines which were Thin-Client machines were not able to run both .NET 1.1 and 2.0 side by side (due to hardware limitations), which resulted in the above set of bugs.
So watch out for this one people, because it is VERY hard fix bugs like this! I would love to hear from other people who have run into this issue, so if you have anything to add to this, please let me know!
Pete Soheil
DigiOz Multimedia
http://www.digioz.com
May 15 2008 15:12
No matter how great your Application works with .NET 1.0 or 1.1, sooner or later people around you are going to start talking about the many advantages of converting it to a 2.0 Project. Not just because the grass is always greener on the other side, but because it is a known fact that the .NET 2.0 Development and Runtime Environment are a lot more stable then 1.0 or 1.1. In addition, Windows Vista does not by default ship with the .NET 1.0 or 1.1 Framework, and although it is possible to run .NET 1.1 on Vista it is NOT recommended to do so (which usually means you can expect plenty of bugs if you do use 1.1).
The actual conversion process from a Visual Studio 2003 (.NET 1.1) Project to a Visual Studio 2005 (.NET 2.0) Project is in fact an automated process. That still however does NOT mean that you won't have any errors and warnings.
So what are some of the Errors and Warnings you are likely to encounter during this conversion process? Bellow is a short list of some of the more common ones and a suggested way to solve the problem. This list is a list of common errors along with a suggested solution that “should” work in most cases. Please note that each occurrence of the warning or error needs to be evaluated on a case by case basis to make sure that it does not change the overall flow, meaning or functionality of the application:
1. Option Strict On disallows operands of type Object for operator ‘=’
Before:Select Case loComboBox.SelectedItem
Case "Value 1"
' Code Here
Case "Value 2"
' Code Here
...
End SelectCorrected:Select Case CType(loComboBox.SelectedItem)
Case "Value 1"
' Code Here
Case "Value 2"
' Code Here
...
End Select2. Variable ‘VariableName’ is used before it has been assigned a valueBefore:Dim loVariable As ObjectC
orrected:Dim loVariable As Object = Nothing3. Variable ‘VariableName’ is passed by reference before it has been assigned a valueBefore:
Dim lsVariable As String
Me.Add(New User(lsVariable))Corrected:Dim lsVariable As String = Nothing
Me.Add(New User(lsVariable))
4. Unused local variable: ‘VariableName’In most cases if the variable is actually not used anywhere it can be deleted. If public and inside of object, it will need to be initiated to “Nothing”.
5. Unreachable code detectedWar This warning simply means that you have written a code segment which can not ever be reached. For example:
Before:Public Function MyFunction (ByVal lsParameter As String) As StringDim lsString as String = lsParameterReturn lsString' Do some more work here that doesn't get executed everReturn lsString2End FunctionCorrected:Public Function MyFunction (ByVal lsParameter As String) As String
Dim lsString as String = lsParameter
Return lsString
End Function6. Type of Parameter ‘ListViewName’ is not CLS-compliantMark Parameter as CLS Non-Compliant using “
_”.
7. Type of Member ‘MemberName’ is not CLS-compliant
Mark Member as CLS Non-Compliant. using “ _”.
8. Name ‘VariableName’ is not CLS-compliant
Mark Variable as CLS Non-Compliant using “ _”.
9. Return type of function ‘FunctionName’ is not CLS-compliant
Mark Function as CLS Non-Compliant using “ _”.
10. Variable declaration without an ‘As’ clause; type of Object assumed.
Before:
Private LandingLockObject = New Object
Corrected:
Private LandingLockObject As Object = New Object
11. Function ‘FunctionName’ does not return a value on all code paths
Before:
Public Function SpecialKey(ByVal keydata As Keys) As String Implements iTerminalEmulator.SpecialKey
Dim lsReturn As String
Select Case keydata
Case Keys.Left
lsReturn = Chr(8)
Case Keys.Down
lsReturn = Chr(10)
Case Keys.Back
lsReturn = Chr(8)
Case Keys.Escape
lsReturn = Chr(27)
Case Keys.Tab
lsReturn = Chr(9)
Case Else
lsReturn = ""
End Select
End Function
Corrected:
Public Function SpecialKey(ByVal keydata As Keys) As String Implements iTerminalEmulator.SpecialKey
Dim lsReturn As String
Select Case keydata
Case Keys.Left
lsReturn = Chr(8)
Case Keys.Down
lsReturn = Chr(10)
Case Keys.Back
lsReturn = Chr(8)
Case Keys.Escape
lsReturn = Chr(27)
Case Keys.Tab
lsReturn = Chr(9)
Case Else
lsReturn = ""
End Select
Return lsReturn
End Function
12. Access of shared member, constant member, enum member or nested type through an instance; qualifying expression will not be evaluated.
Happens when either a Shared member in a class is not referenced through the class name, or two programming elements have the same name (for example you have a function and a variable both of which have the same name). To solve, either use the name of class or structure that defines the Shared Member to access it, or look through the code and either rename the variable or the function to something different.
Pete Soheil
DigiOz Multimedia
http://www.digioz.com
Mar 18 2008 20:43
For those of you who have never heard of "
Second Life", it is an online 3D Virtual Environment that has been built entirely by its users using a set of built in utilities and basic 3-Dimensional Shapes and modifying their size and texture. At first glance the game reminded me a bit of another 3D Game called "Sims". But soon I realized that this one is a lot more then just a game, its a virtual paradise for Scientists, Engineers, Programmers, 3D Animators as well as the average user that knows nothing about any of the above skills all at the same time.
The beauty of Second Life is that it can be as simple or as complex to users as they want it to be. If the user is simply trying to use Second Life to socialize with other users, they can do that and never have to touch a program or create a single graphic object by simply using what others have already created. On the other hand advanced users can use a combination of 3D Modeling and Programming, along with a set of Second Life Physical properties such as Gravity and Wind to build and test real life structures and create a visually presentable version of their design concepts, which can then immediately be experienced by other users! Here is an example of the types of structure that are possible in Second Life:
As a programmer who has been on the World Wide Web from the beginning, I see Second Life type technologies as the future of the Internet. Imagine an Internet where you can touch, feel and see things in 3 dimensions, and where you can design actual store fronts to have visitors "Walk" through the door and pick up products and experience it first hand before buying!
Pete Soheil
DigiOz Multimedia
http://www.digioz.com/
Jan 06 2008 18:47
