Conditional compiling

[lgs.lgs]

I need to be able to support multiple versions of c#. Does the compiler
define any #defines so you can tell if you are compiling for.NET 1.1 or 2.0?

[Bruce Wood]

I'm sure that you have a good reason, but I'm curious... why?

[Andy]

I wouldn't think so. Its a different compiler when targeting 1.1 or
2.0, which is why VS 2005 only works with 2.0 and 2003 1.1.

FWIW, you should be able to compile to 1.1, and still have your
assembly loaded by .net 2.0 if you need to. Just take your 1.1
assembly and reference in your 2.0 project... should work just fine.

[Bruce Wood]

I'm not 100% sure, but I would assume that if you need to target both
systems with the 2.0 Framework and other systems that have only the 1.1
Framework, you would simply stick to VS2003.

Although I can't make a solid claim to this, I believe that code
compiled for 1.1 will run on systems that have only the 2.0 Framework
installed. We have tried code that we have written here on a machine
that has only 2.0, not 1.1, and it runs fine, and we are still on
VS2003.

Of course, our code does not exercise all of the capabilities of the
Framework, so there may be version incompatibiliti es, but in this
newsgroup I've heard of only one.

[Jon Skeet [C# MVP]]

Andy <aj*****@alum.r it.edu> wrote:

I wouldn't think so. Its a different compiler when targeting 1.1 or
2.0, which is why VS 2005 only works with 2.0 and 2003 1.1.
There's no reason why you shouldn't run the two compilers on the same
code and get different results though...
FWIW, you should be able to compile to 1.1, and still have your
assembly loaded by .net 2.0 if you need to. Just take your 1.1
assembly and reference in your 2.0 project... should work just fine.

That's not terribly easy if you want to provide an API which uses
generics in 2.0 but not in 1.1...

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Andy]

<i>There's no reason why you shouldn't run the two compilers on the
same
code and get different results though... </i>

You may get different results using a different complier, but if you
compiled with the 1.1 compiler, the bytecode produced should run just
fine on 2.0 as well.

<i>That's not terribly easy if you want to provide an API which uses
generics in 2.0 but not in 1.1... </i>

The poster wanted to run the same code though two different compilers,
he didn't say anything about using the new features in 2.0 (which I
assume he wouldn't want to, because I got the impression he wanted a
single code base, not branched versions).

[Jon Skeet [C# MVP]]

Andy <aj*****@alum.r it.edu> wrote:

<i>There's no reason why you shouldn't run the two compilers on the
same
code and get different results though... </i>

You may get different results using a different complier, but if you
compiled with the 1.1 compiler, the bytecode produced should run just
fine on 2.0 as well.
Yes, but you may find that you're limited in terms of options - you
can't provide (or use) generics, for instance.
<i>That's not terribly easy if you want to provide an API which uses
generics in 2.0 but not in 1.1... </i>

The poster wanted to run the same code though two different compilers,
he didn't say anything about using the new features in 2.0 (which I
assume he wouldn't want to, because I got the impression he wanted a
single code base, not branched versions).

You can have a single source code base which produces a richer API for
..NET 2.0, however.

Put it this way - I've been considering a few situations where I've
wanted exactly this functionality - to produce one version of a library
for use by .NET 1.1 clients, and a different version for use by .NET
2.0 clients. Of course, .NET 2.0 clients *could* use the 1.1 library,
but they'd get extra features if they used the 2.0 version.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Andy]

>Yes, but you may find that you're limited in terms of options - you

can't provide (or use) generics, for instance.
True, but thats what you have to do if you really want to target both
frameworks with a single codebase.
You can have a single source code base which produces a richer API for
.NET 2.0, however.
Currently I don't see how; run .Net 2.0 specific code through the 1.1
compiler, and you'll get errors.
Put it this way - I've been considering a few situations where I've
wanted exactly this functionality - to produce one version of a library
for use by .NET 1.1 clients, and a different version for use by .NET
2.0 clients. Of course, .NET 2.0 clients *could* use the 1.1 library,
but they'd get extra features if they used the 2.0 version.

I don't think its there however, and I doubt it will be. I believe MS'
position on this is that if you want to target 1.1 and up, you target
1.1.

I'd also have to think that managing a codebase using #define
directives would be pretty expensive. You'd have to have two sets of
tests, since you're compiling different code based on a flag. It
hardly seems like it'd be worth the trouble.

[Jon Skeet [C# MVP]]

Andy <aj*****@alum.r it.edu> wrote:

Yes, but you may find that you're limited in terms of options - you
can't provide (or use) generics, for instance.

True, but thats what you have to do if you really want to target both
frameworks with a single codebase.

Not really. Often there may be fairly small differences between the
code supporting the different versions - differences which are small in
terms of lines of code but very important from the point of the view of
the user of the class.

You can have a single source code base which produces a richer API for
.NET 2.0, however.

Currently I don't see how; run .Net 2.0 specific code through the 1.1
compiler, and you'll get errors.

Not if you've conditionalised the code though - and that's what the OP
wants, from the way I read it.

Put it this way - I've been considering a few situations where I've
wanted exactly this functionality - to produce one version of a library
for use by .NET 1.1 clients, and a different version for use by .NET
2.0 clients. Of course, .NET 2.0 clients *could* use the 1.1 library,
but they'd get extra features if they used the 2.0 version.

I don't think its there however, and I doubt it will be. I believe MS'
position on this is that if you want to target 1.1 and up, you target
1.1.

I'd also have to think that managing a codebase using #define
directives would be pretty expensive. You'd have to have two sets of
tests, since you're compiling different code based on a flag. It
hardly seems like it'd be worth the trouble.

It depends on the benefits gained by using the 2.0 features. In some
cases there could be *massive* benefits. I was considering writing a
mock object framework in C# (a successor to EasyMock.NET) which would
have been significantly easier to use in 2.0 with generics, but which
I'd still have wanted a 1.1 version of.

It would certainly be easier to share 90% of the code than to maintain
two separate codebases which contained the same logic but slightly
different APIs. *Then* I really would need to double the test effort,
instead of having one set of common tests, one which only ran on 2.0
and one which only ran on 1.1.

Now, it could well be that you're right about MS's point of view - but
that doesn't mean it's not feature which could be very, very useful to
some people. MS has been known to miss the boat on things before - look
at how many people want to be able to target 1.1 with VS 2005 (and the
subsequent MSBEE effort.)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[lgs.lgs]

Just to follow up here. In general, Jon has pretty much stated my case for
me.

My project requirements include delivering source code, and the target
audience is varied. Even without using any new 2.0 features, just getting a
clean compile requires changes.

So I either need to make two source trees with 99%+ of the code being
identical (and remember to make all future changes twice), or I need to have
1 tree with a few #if statements: ~50 in the ~25,000 lines of code, most of
which wrap a single line.

It's not like I'm talking about a brand new concept. MS's C compiler has
supported this for forever (see _MSC_VER in
http://msdn2.microsoft.com/en-us/lib...y(VS.80).aspx). Heck, they
even have a __CLR_VER. Of course they also support #if __CLR_VER > xxx.

At this time, my solution is to have two sets of sln+csproj files (which I
have to have anyway), and to have USING_NET11 defined in the old project
file. I believe it would have been cleaner to use a well-known,
compiler-defined variables for this, but apparently that was not meant to
be. As near as I've been able to discover, there aren't *any* compiler
defined defines.

Thanks for the posts.