Fog Creek Software
Discussion Board




This is why I am not a .NET fan

http://www.gotdotnet.com/team/changeinfo/default.aspx

I knew this was coming the day they announced .NET.  This is just another version of DLL hell.  Microsoft has still not solved their issues with backward compatibility.

On the other hand, other products, like Delphi, totally encapsulate all of their libraries into one executable.

Bryan Shaw
Wednesday, May 21, 2003

It was my understanding that he frameworks installed side by side, and that you specify in the app against which framework it should run.
Sure, there will be interesting problems, but hopefuly not the "there can be only one" rampage of DLL Hell.

See "The Dawn of Framework Hell? Early & Adopter on : Running Multiple Versions of the Framework Side-by-Side"
http://www.3leaf.com/default/articles/ea/SBS.aspx

Just me (Sir to you)
Wednesday, May 21, 2003

>I knew this was coming the day they announced .NET

"The only constant is change."  If you want to maintain backwards compatibility, you forsake bug-fixes, security updates, etc. 

I personally don't see what you're crying about.  Java's no better.  There are plenty of apps, applets, app servers that won't work with version 1.<insert minor revision here>.

This has all to do with the class library and not the platform itself.  Write your own libraries and you won't have to worry (for the most part) about this stuff.  Just be prepared to do a shitload of work to implement everything microsoft has put into the class libraries.

Next topic please.

GiorgioG
Wednesday, May 21, 2003

No, its pretty broken if the following happens:

"Warning  Updating a Visual Studio .NET version 1.0 Project

If you open a project built with Visual Studio .NET version 1.0 in Visual Studio .NET version 1.1, you will get a warning saying that the project will be automatically upgraded to Visual Studio .NET version 1.1 and your application will be upgraded to execute on the .NET Framework version 1.1. After the project is opened in Visual Studio .Net version 1.1, you cannot open it in Visual Studio .NET version 1.0. This is true even if you do not rebuild your application. Furthermore, opening your project in the later version of Visual Studio does not automatically guarantee that your application will still compile and run."

Simon Lucy
Wednesday, May 21, 2003

http://www.codeproject.com/useritems/VSConvert.asp?target=project%7Cconvert

GiorgioG
Wednesday, May 21, 2003

"Although it is possible to target version 1.0 of the common language runtime from Visual Studio .NET 2003, it is highly recommended that you use Visual Studio .NET 2002 for that instead. You can install and run both versions side-by-side on the same computer."

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbconWorkingWithMultipleVersionsOfNETFramework.asp

Just me (Sir to you)
Wednesday, May 21, 2003

Ummm, a development system that needs squirrelly utilities to be useful?  It kind of smells of the tar that VB was brushed with.

Simon Lucy
Wednesday, May 21, 2003

"If you're targeting version 1.0 only and you're desperate to use Visual Studio .NET 2003, but just can't give up the compiler-time checking and accurate IntelliSense, there is a way to eat your cake and have it too. Unfortunately, you'll be without frosting, as you'll have to do more than just flip the bit in the .NET Framework Version dialog. First, you'll have to set Project | Properties | Configuration Properties | Advanced | Do not use Mscorlib to "true" (it defaults to "false") so that you don't pull in the version 1.1 mscorlib.dll when you're compiling. Second, you'll have to remove all of the assembly references that Visual Studio .NET 2003 adds to your project, as it will default to getting them from the version 1.1 Framework directory. Finally, you'll have to add project references from the version 1.0 Framework directory using the browser button in the Add Reference dialog to choose assemblies manually (including mscorlib.dll and system.dll). Since the compiler (and IntelliSense) will be referencing the version 1.0 assemblies, these manual steps let you continue to use Visual Studio .NET 2003, even for version 1.0-only assemblies."

http://msdn.microsoft.com/msdnmag/issues/03/03/WindowsForms/

Just me (Sir to you)
Wednesday, May 21, 2003

Simon,

That's a pretty weak argument considering a development environment/system is nothing but a bunch of utilities linked together by an interface. 

Yes, it could have been included in VS.NET2003 but it wasn't.  I don't understand why you'd be going between 2003 & 2002 anyway since 2003 can target the 1.0 framework. 

This is like any other piece of software: There's many things that could make it better, but at some point you say 'good enough' and release it.

GiorgioG
Wednesday, May 21, 2003

Well this is meant to be more than a weak linkage of development utilities and a class framework; its meant to be the language of God and His Maker.

.Net is hardly out of swaddling clothes and it needs changing already?  And changing already in a way which makes it awkward to support and maintain what's already out there?  Not impossible but awkward.

Awkward is worse than impossible, its more expensive than impossible it takes more resources than impossible.

Impossible makes it clean and easy to make the decision as to what to do, awkward is being killed by a million tiny cuts.  I suffered and belaboured in the mines of Mozilla but I could always bathe my wounds in the Holy Spirit of Open Source and the knowledge that it was bound to be messy.

To hang future development on .Net now seems a leap in the dark rather than a cool snowboarding stunt.  Its all very well to be able to do cool stuff in code by ooooh just doing it man, but when you get screwed into upgrading all the development tools and all the runtimes just to keep the build going it isn't so cool. 

Its just lame.

Simon Lucy
Wednesday, May 21, 2003

Then don't upgrade.

There's plenty of shops still using VC6.

GiorgioG
Wednesday, May 21, 2003

Haven't a lot of version 1's had drastic upgrade issues between it and it's next point release?  If in the next upgrade or so it's as painful I'll worry. 

I am remembering the AWT of 1.0 to 1.1 with java, then finally to Swing. 

It's just the problem with having a pretty original 1.0.  There's gonna be teething problems.  If version 2 -> 3 are still having them then worry!

Colin Newell
Wednesday, May 21, 2003

It's nice working with programming languages that don't require anything more than a text editor.  I've worked with Visual Studio in the past.  Once was enough (actually it was a few times).


Wednesday, May 21, 2003


Umm... none of the .NET languages require more than a text editor... for the actual programming, that is. I don't know any language that can be used to create and execute programs without the aid of some other external resource...

You can download the .NET SDK for free off of Microsoft's web site and do all your programming in Notepad, if you want. Visual Studio does not offer anything that you can't get from somewhere else, it just increases productivity.

Finally, the key point here was made by Giorgio (I think - I'm too lazy to go back and check): this is not DLL Hell. By allowing multiple versions of the same DLL to exist, Microsoft is offering the complete opposite of DLL Hell. You may not like it that the new APIs break old code, but this is bound to happen as bugs are fixed and design is improved. The difference between .NET and Java or any C/C++ framework is that you can "upgrade without upgrading" - your machine can run 1.0 and 1.1 applications.

Dan J
Wednesday, May 21, 2003

Dan,

FYI - Java supports the ability to run multiple versions of Java VMs on the same machine as well.

Seeker
Wednesday, May 21, 2003

The framework is not the VM.
Or at least it's much more than the VM.

mb
Wednesday, May 21, 2003

Storm in a teacup.

From the article:

"Backward compatibility means an application written for the .NET Framework version 1.0 can execute on version 1.1. The .NET Framework provides the highest degree of support for backward compatibility. Most applications that work on the current version of the .NET Framework will work on the next version of the .NET Framework."


We have a fairly large application that compiles and runs perfectly under both 1.0 and 1.1.

Are there going to be issues? Of course. But to somehow draw the conclusion that that compatibility problems is the sole domain of Microsoft is just plain nuts.

Mark Hoffman
Wednesday, May 21, 2003

".Net is hardly out of swaddling clothes and it needs changing already? " -- well no not really, all our code compiles and runs just fine on both frameworks - the majority of changes are either behind the scenes or just the inclusion of things that were previously separate from the main framework - e.g. ODBC, PocketPC, Mobile ASP.NET stuff, etc. ie, it's a superset really, which as far as we've found is very backwards compatible. In fact, we still build our code using the 1.0 compiler even though we develop on VS2003 as there's nothing yet we require 1.1 for. Our "proper" build is done by a script which anyone with the framework installed can run.

Duncan Smart
Wednesday, May 21, 2003

That's good to hear and I understand that in principle the frameworks are compatible and that you don't have to use Visual.

But you're still using the 1.0 IDE and as I understand it as soon you use 1.1 on any development machine it will upgrade it and you'll have to upgrade all development machines?  Or do  I have that wrong?

Simon Lucy
Wednesday, May 21, 2003

Simon,

No, using 1.1 will not upgrade everything on your machine. The frameworks are designed to run side-by-side. That means that when you install 1.1, 1.0 is still there running exactly as before.

In fact, right now I have VS.NET 2002 and 2003 open and running on this machine. There are no conflicts and they don't interfer with each other, and niether do the frameworks.

What might have you confused is Visual Studio 2003's upgrade behaviour. If you open a project that was originally created with VS2002 in VS2003, 2003 will upgrade the project's file formats (the .vsproj and company, not your source code files). Those project files cannot be opened in 2002.

Hope this clears things up,

Ian.

Ian Lowe
Wednesday, May 21, 2003

Ahhhh, only slightly awkward then.

Ta.

Simon Lucy
Wednesday, May 21, 2003

All the microsoft haters grabbing on to any little thing to whine about.

Whine. Whine.

There is no development environment or toolset that even approaches the power of .NET.

Oh, and Delphi users, get over it, your time is over.

Realist
Wednesday, May 21, 2003

If you open a 2002 project file, it will be upgraded to 2003, and incompatible with 2002. So, yes, if you upgrade to 2003 for your existing projects, it's an all-or-nothing thing.

Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, May 21, 2003

But of course, I should point out that VS.NET 2002 and 2003 will exist side-by-side just fine.

Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, May 21, 2003

Some of you seem to have missed the great link GiorgioG provided before:

http://www.codeproject.com/useritems/VSConvert.asp?target=project%7Cconvert

"I decided to create a utility that converts projects from the new Visual Studio .NET 2003 (codename "Everett") to Visual Studio .NET 2002. This is because in my experience I was working with both and found it hard to manually convert the projects and it often introduced problems, so I made an automated tool to do this job for me. So, all who are having the same difficulty, this tool is for you.

I've included full source code so you can see how I've done it and also so you can customize the tool to fit your own needs. You could even use the same framework to make a tool that converts VS 7.0 solutions back to VS 6.0.

So, you may ask, "How did you know how to convert the project files?" Here is a step-by-step description of the changes that happen when you convert a project from VS 7.1 to VS 7.0.


In SLN files, the 8.0 must be replaced with 7.0.
In vcproj files (and only vcproj), the 7.10 part must be replaced by 7.0.
In VB.NET or C# project files, 7.10.xxxx is replaced with 7.0.9466, where xxxx is the build number of VS.NET 7.1
Also in VB.NET and C# projects, the schema version 2.0 should be replaced with 1.0.
In RESX files, the types declared are 1.0.5000 and must be replaced with 1.0.3300.
Finally, in RESX files (binary streams), the base-64 encoded part that describes the version of the stream must change from LjAuNTAw to LjAuMzMw (basically base-64-encoded versions of 1.0.5000 and 1.0.3300 respectively)
"

Just me (Sir to you)
Thursday, May 22, 2003

My central point is that you still have to worry about what is on the user's computer.  The user still has to have both versions of the Framework installed in their computer for all the apps to work.  With Delphi, you don't have to worry about that at all!

The worst case scenario had to do with upgrading a project from Delphi version 3 to Delphi 6.  We had over 225 workstations where this app was being used on a daily basis. 

Development work to upgrade that project, with over 1.5 million lines of code, took less than 30 man hours.

Implementation on the user's desktop was as simple as replacing the executable file.  Period!  And it worked, flawlessly the next day!

Bryan Shaw
Thursday, May 22, 2003

And after upgrade projects from Delphi version 3 to Delphi 6 you are still able to open projects with version 3 just fine? I can't get it - you are saying that answering "Yes" to upgrade project file in VS 2003 is worse then spending 30 hours to upgrade from Delphi 3 to 6...

WildTiger
Thursday, May 22, 2003

Pretty much every development environment of any consequence on the Windows platform has an associated runtime (C++ runtime DLLs for most C++ compilers, VB runtime for VB, etc.). Add onto that the fact that many applications will leverage potentially optional components (like, say, require a specific minimum version of IE or MDAC), and I'd say the question is pretty much moot.

The problem isn't limited to Windows. It also exists on Linux, where entire software solutions have been devised just to find and populate the dependent software for an application (RPM, apt, and the gentoo builder all do this, as an example).

Brad Wilson (dotnetguy.techieswithcats.com)
Friday, May 23, 2003

Oh, and here's something else to consider.

Every runtime library you use creates this requirement dependency. It used to be that you couldn't assume the user had Windows (back in the late 80s, early 90s), so some software shipped with a cut down version of it (like Aldus PageMaker). Now, we all assume Windows is there.

Every leverageable component goes through the cycle of adoption. At the early stages, hardly anybody has it. As apps get deployed for it, and it gets integrated into the OS, it starts to get wider coverage, until the day when it's finally essentially everywhere. We're just in the early stages of .NET. It will be there, one day, ubiquotously.

Brad Wilson (dotnetguy.techieswithcats.com)
Friday, May 23, 2003

*  Recent Topics

*  Fog Creek Home