While the 'supported runtimes' feature is of minimal value, it is possible to convince VS.NET 2003 to build against the v1.0 binaries. You have to disable the use of standard libraries, and then point it directly at the old versions of mscorlib and any other system libraries you use.
This does seem to produce binaries that look like they want to run with v1.0.
But I have to admit to not having tried to ship anything this way. I've tended to go with NAnt for repeatable build processes so far.
As for MSBuild, I was at a talk by Kieran Mockford, a PM from the MSBuild group, a couple of months ago. From what I remember, the intention was to support targetting of multiple versions of the runtime. VS.NET templates might not be set up that way, but I thought the MSBuild technology itself was going to support this.
-- Ian Griffiths - http://www.interact-sw.co.uk/iangblog/ DevelopMentor - http://www.develop.com/
----- Original Message ----- From: "Shawn A. Van Ness" <[EMAIL PROTECTED]>
Visual Studio .NET doesn't support the ability to build against any version of the framework other than the one it simul-shipped with. (Don't talk to me about the "supported runtimes" project property -- that option doesn't exist at all for library assemblies -- it's just an app.config hack, and really *not* a good idea for production apps, hence all the warnings on that dialog.)
VS 2003 only builds against .NET v1.1, and by all accounts it looks like Whidbey VS/MSBuild is only going to target v2.0. (Someone please tell me if I'm wrong about that... please, I beg you, tell me I'm wrong.)
I work for a small ISV, and our product is a class library -- an SDK, if you will.
What are we to do? Ideally we'd like to be able to use the latest-and-greatest IDE, with whatever spiffy new Intellisense features and other bug fixes and enhancements -- but we can't afford to cut down our potential target market to just those who are willing to build their apps against the latest-and-greatest framework. If we took that approach, we'd effectively be resetting our customer base to zero, upon the release of every new version of the framework...!
So, I began looking to MS for inspiration -- the Tablet PC SDK and the DirectX SDK both include managed wrapper libraries -- what do they do? They take slightly different tracks, but both involve shipping down-level builds: The latest Tablet SDK was released along with XP SP2, but the managed wrapper is still built against the v1.0 framework. The latest DirectX SDK, on the other hand, seems to include a pair of identical (?) managed wrappers built against the v1.0 and v1.1 frameworks (v1.0.900.0, in a folder named v4.09.00.0900, targets v1.0.3300 -- while v1.0.2902.0, in a folder named v9.02.3900, targets v1.1).
Now, I can't begin to comprehend the schizophrenic versioning strategy of the DirectX bits -- the file/product-version attributes on those assemblies are an altogether *different* set of numbers, if you can believe that! But the Tablet PC approach makes sense to me: as long as newer runtimes can execute code built against older frameworks, just build the library to the earliest possible framework, and be done with it.
But does this mean I have to use VS 2002 for the rest of my life? If not, what choice do I have? What is everyone else doing?
It looks like NAnt offers the ability to target down-level runtimes...? I can't tell -- I couldn't quite get it to work for me. (The <solution> task crashed on me when I attempted a v1.0 build while pointing to a VS2003 .csproj file.) NAnt still hasn't reached 0.9, and I worry development and maintenance will drop off even further once MSBuild gets here.
So, over the holidaze I wrote my own little build tool to parse VS2003 .csproj files and feed the various source files to the command line C# compiler. Works great, but now I've run into a wall with resources and localization: I can feed the .resx files to v1.0 resgen.exe easily enough, but what about their content? The .resx files created by VS2003 are chock full of references to things like "System.Boolean, mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".
I could probably search-and-replace those assembly references with the corresponding v1.0 numbers, but then what about all the base64-serialized goo (icons, bitmaps, imagelists, and the like) that gets thrown into those .resx files? Am I supposed to back-convert all that, somehow? Is that even possible? Does NAnt attempt to correct for this, somehow, when targetting different runtimes? (Or, is that why it bombed on me?)
Someone please give me a clue... currently, I'm considering imposing a "no binary resources in .resx files" policy on my team, just so we can build down-level and still have a story for localization. (That may not be a bad course of action, really -- I've always hated the idea of .resx files keeping copies of my icons and bitmaps and such buried away, invisible to the naked eye, and out of sync with their real-file coutnerparts in source control, etc).
I'm just hoping there's a simpler alternative I've overlooked...?
=================================== This list is hosted by DevelopMentor� http://www.develop.com Some .NET courses you may be interested in:
Essential .NET: building applications and components with C# November 29 - December 3, in Los Angeles http://www.develop.com/courses/edotnet
View archives and manage your subscription(s) at http://discuss.develop.com
