morty@home

Bryan Little blogs about some info Franci Penov (Microsoft) posted about Avalon and Longhorn.

It is different as programming paradigm and prowides a lot more features than the current Windows Forms. It should be used instead of Windows Forms for native Longhorn apps.

I'm really looking forward to finding out more about this framework. I'm not usually excited about GUI technology, but Avalon seems very interesting ;)

Andreas Eide blogs about side by side issues with VS.NET 2002 and VS.NET 2003.

So, I have this project developed in Visual Studio .NET 2003 that I want to use at the customer site. At first I only needed the executables, so I set up Visual Studio .NET 2003 to compile to v1.0.3705 of the framework. This worked just fine. But now I want to use the source code at the customer site. I can’t open the VS.NET 2003 solution with VS.NET 2002. It says that the file is not a valid solution file. And I have found no way in VS.NET 2003 to save the solution in 2002 format.

This got me thinking about an article I read over at www.codeproject.com, so I did a quick search and found this tool; A Utility to Convert VS.NET 2003 Project Files.

Even though it is fairly annoying not being able to do a test compile of your current solutions without converting all the solution, project and resource files, this tool may be able to help ease some of the pain.

At the risk of relighting an old debate I feel that I need to type down a few thoughts on the topic of .Net language interoperability. Over the last couple of years I’ve been in countless .Net discussions, and quite a few of them have at one point or another touched this specific topic. Either it is a Java supporter claiming that this feature is effectively useless and will eventually create chaos or the never ending debate about whether C# or VB.NET is the wave of the future. This over-discussed yet underappreciated topic has none the less inspired me to publish a slightly different point of view.

I feel that a large part of the people I talk assume that language interoperability is all about making the right decision about what general purpose programming language to use, or if you read the marketing slogans; not making that decision at all. And I guess in a lot of cases it probably is. Yet it seems to me that one of its most appealing opportunities is effectively ignored.

The interesting thing about language interoperability is, in my opinion, not about making a choice between general purpose programming languages, but rather about all the cool special purpose languages that are or will be available. Today we have a regular expressions compiler, and soon we will probably have a XSLT compiler. Then we will most likely have the database languages, the reporting languages, the mathematical and scientific languages and of course the process and abstract state machine languages. And all of these different compilers will transform their various input formats into verifiable and easily accessible IL modules.

To me this is the true beauty of the language interoperability feature. It provides you with the opportunity to utilize languages that are designed to greatly simplify specific tasks, and then effectively integrating these languages with the general purpose programming language of your choice. This is what makes me hit the download button every time I see a new managed compiler. And quite honestly, whether you choose MC++, C# or VB.NET to do your work is no longer exiting or refreshing conversation material.