Targetting a class library for both 3.5 and 2.0

[=?ISO-8859-1?Q?Lasse_V=E5gs=E6ther_Karlsen?=]

I have a rather big class library solution with lots of projects.

Some of these projects I'd like to include .NET 3.5 things in, but only
when I'm targetting 3.5.

Basically, I'd like to be able to target 3.5 and rebuild, getting new
things into the new dll's for 3.5, and also be able to target 2.0 and
rebuild, to get files for 2.0.

What is the best way to do this? The "best" way I've come up with so far
is to make a new solution file and new project files with a named
definition and use #if..#endif to make files, or just not include the
3.5 files in the 2.0 projects, but this seems like a rather big
maintenance nightmare.

I'd like to have one solution and all of the projects once, and include
files that may or may not produce any compiled code depending on the target.

Or am I way off target here? Any thoughts would be welcome.

 

[Samuel R. Neff]

Can't you just #if/#endif wrap the entire class definitions within the
3.5-specific classes? I don't see the need for extra solution files
or separate projects.

The complicated parts will be when there are interdependencies and
making sure that a 2.0 tareted class does not reference a 3.5-only
class. You'll find this pretty quick with automated build of both
targets thought (continuous integration would be good here). However,
keeping 3.5 specific stuff to an entirely 3.5-specific project would
make this process even easier.

HTH,

Sam

 

[=?ISO-8859-1?Q?Lasse_V=E5gs=E6ther_Karlsen?=]

Can't you just #if/#endif wrap the entire class definitions within the
3.5-specific classes? I don't see the need for extra solution files
or separate projects.

I guess that leads me to the next question, are there predefined define
names that are automatically set by 2.0 and 3.5? otherwise I'd need
project-settings for these?

ie.

#if <what goes here for 2.0 or 3.5?>

 

[Jon Skeet [C# MVP]]

I guess that leads me to the next question, are there predefined define
names that are automatically set by 2.0 and 3.5? otherwise I'd need
project-settings for these?

ie.

#if <what goes here for 2.0 or 3.5?>

They're not defined by the framework - they're defined by Visual Studio
(being compile-time only). However, I don't believe there are any
"standard" ones beyond TRACE and DEBUG.

 

[=?ISO-8859-1?Q?Lasse_V=E5gs=E6ther_Karlsen?=]

They're not defined by the framework - they're defined by Visual Studio
(being compile-time only). However, I don't believe there are any
"standard" ones beyond TRACE and DEBUG.

So basically I either have to make two project files, containing
different directives, or change them each time in the single project file?

 

[=?ISO-8859-1?Q?Lasse_V=E5gs=E6ther_Karlsen?=]

So basically I either have to make two project files, containing
different directives, or change them each time in the single project file?

I guess I'll make new projects for the 3.5 parts.

 

[Jon Skeet [C# MVP]]

I guess I'll make new projects for the 3.5 parts.

I think that's the only sensible way to go - because I don't believe
you can have conditional *references*, and you don't really want .NET
3.5 references in an assembly running in .NET 2.0, I suspect...

 

[=?ISO-8859-1?Q?Lasse_V=E5gs=E6ther_Karlsen?=]

I think that's the only sensible way to go - because I don't believe
you can have conditional *references*, and you don't really want .NET
3.5 references in an assembly running in .NET 2.0, I suspect...

You're right.

Looks like I finally get to test out the branching capabilities of
Subversion I guess

I won't be doing much development in 2.0 mode from now, but bugfixes
will be present, so I think I'll just branch off for 2.0, and change
everything to 3.5 for the main trunk.

I've identified a lot I want to change for 3.5 anyway, to take advantage
of new features, and having #if...#endif everywhere will be hard to
maintain for long I think.

Thanks for the input.

 

[Jon Skeet [C# MVP]]

You're right.

Looks like I finally get to test out the branching capabilities of
Subversion I guess

The good news is that Subversion branching support is wonderful

I won't be doing much development in 2.0 mode from now, but bugfixes
will be present, so I think I'll just branch off for 2.0, and change
everything to 3.5 for the main trunk.

That makes a lot of sense.

Jon