By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,992 Members | 1,344 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,992 IT Pros & Developers. It's quick & easy.

Conditional compiling

P: n/a
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?
Mar 28 '06 #1
Share this Question
Share on Google+
10 Replies


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

Mar 28 '06 #2

P: n/a
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.

Mar 28 '06 #3

P: n/a
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 incompatibilities, but in this
newsgroup I've heard of only one.

Mar 28 '06 #4

P: n/a
Andy <aj*****@alum.rit.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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 29 '06 #5

P: n/a
<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).

Mar 29 '06 #6

P: n/a
Andy <aj*****@alum.rit.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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 29 '06 #7

P: n/a
>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.

Mar 29 '06 #8

P: n/a
Andy <aj*****@alum.rit.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.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Mar 29 '06 #9

P: n/a
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.
Mar 29 '06 #10

P: n/a
> Even without using any new 2.0 features, just getting a clean compile requires changes.

Now you've piqued my curiosity... what changes are required?
MS's C compiler has supported this forever.


Actually, ANSI C has supported this forever. However, C# isn't C, and
in particular C# doesn't have a precompiler and the # directives that
go along with it. I say thanks to Anders Hejlsberg and the C# team for
that-C's macros were often horribly abused-but others' reactions
may vary. :)

Mar 30 '06 #11

This discussion thread is closed

Replies have been disabled for this discussion.