Building .NET 3.0

[Mike Schilling]

I recently installed the .NET 3.0 framework (behind the time, I know), and
am seeing an issue building it.

Because 3.0 doesn't upgrade csc.exe, I'm still using the 2.0 csc to build
things. Since the assemblies added in 3.0 aren't in the 2.0 directory tree,
their names need to be fully qualified, so I wind up with command lines
like:

csc /r:"c:\WINDOWS\Microsoft.NET\Framework\v3.0\Windows Communication
Foundation"\System.Runtime.Serialization.dll ParseXml.cs

Did I miss some way to simplify this, or is that just how it works?

 

[Scott M.]

Just a small correction about your question: it doesn't relate to
"building", it relates to "compiling". Building is taken care of by
msbuild.exe and is a different than compiling.

As for your compiling, are you using a version of Visual Studio? If so, you
shouldn't have to do any command line work.

 

[Ignacio Machin ( .NET/ C# MVP )]

I recently installed the .NET 3.0 framework (behind the time, I know), and
am seeing an issue building it.

Because 3.0 doesn't upgrade csc.exe, I'm still using the 2.0 csc to build
things.  Since the assemblies added in 3.0 aren't in the 2.0 directory tree,
their names need to be fully qualified, so I wind up with command lines
like:

csc /r:"c:\WINDOWS\Microsoft.NET\Framework\v3.0\Windows Communication
Foundation"\System.Runtime.Serialization.dll ParseXml.cs

Did I miss some way to simplify this, or is that just how it works?

Out of curiosity, why don't you simply install 2008 express?

 

[Mike Schilling]

Out of curiosity, why don't you simply install 2008 express?

We have a mixed environment, of which .NET is only a fraction, and thus our
build environment is command-line driven rather than .NET-centric. Nor do I
want to have to install and maintain VS.NET on headless machines used only
to do builds.

Anyway, that all aside, is there a way to simplify these command lines, or
do the assembly names have to be fully qualified?

 

[Jon Skeet [C# MVP]]

We have a mixed environment, of which .NET is only a fraction, and thus our
build environment is command-line driven rather than .NET-centric. Nor do I
want to have to install and maintain VS.NET on headless machines used only
to do builds.

So use MSBuild - create project/solution files with Visual Studio, and
just run MSBuild on those and let it deal with everything.

Anyway, that all aside, is there a way to simplify these command lines, or
do the assembly names have to be fully qualified?

You could add the references to the default response list for csc.

 

[Arne Vajhøj]

I recently installed the .NET 3.0 framework (behind the time, I know), and
am seeing an issue building it.

Because 3.0 doesn't upgrade csc.exe, I'm still using the 2.0 csc to build
things. Since the assemblies added in 3.0 aren't in the 2.0 directory tree,
their names need to be fully qualified, so I wind up with command lines
like:

csc /r:"c:\WINDOWS\Microsoft.NET\Framework\v3.0\Windows Communication
Foundation"\System.Runtime.Serialization.dll ParseXml.cs

Did I miss some way to simplify this, or is that just how it works?

msbuild, Csc task, AdditionalLibPaths + References attributes

or

nant, csc task, references nested element and ant style fileset

Arne

 

[Mike Schilling]

So use MSBuild - create project/solution files with Visual Studio, and
just run MSBuild on those and let it deal with everything.

Does MSBuild integrate well with Ant? That's what drives the build (Ant has
build-in tasks to run csc, ilasm, etc.)

You could add the references to the default response list for csc.

Aha! And how do I do that?

 

[Jon Skeet [C# MVP]]

Does MSBuild integrate well with Ant? That's what drives the build (Ant has
build-in tasks to run csc, ilasm, etc.)

There's an MSBuild task in the Ant .NET library:
http://ant.apache.org/antlibs/dotnet/

Alternatively just execute it with exec task.

Aha! And how do I do that?

Find csc.rsp in your framework directory and edit it. It's not a
terribly nice way of doing it though - running MSBuild would be much
better.

 

[Arne Vajhøj]

Does MSBuild integrate well with Ant? That's what drives the build (Ant has
build-in tasks to run csc, ilasm, etc.)

I would find it tempting to use nant because:
- nant supports everything you will need
- the nant syntax is so close to ant that it will be easy to use

Arne

 

[Mike Schilling]

I would find it tempting to use nant because:
- nant supports everything you will need

As I said above, .NET is a fraction of the entire build. Ant does a
fine job of running command-line programs, and I suspect nant does a
poor one of invoking the Java compiler within its active JVM.,

 

[Alex Meleta]

Hi Mike,

Because csc doesn't automatically resolve references to GAC assemblies than
using DOS variables can be the way. For instance, folllowing example simplifying
your input just to use the variables:

@set net20path=%windir%\Microsoft.NET\Framework\v2.0.50727
@set net30path=%windir%\Microsoft.NET\Framework\v3.0
@set net30wcfpath=%net30path%\Windows Communication Foundation
@set csc=%net20path%\csc.exe

@set refserialization=%net30wcfpath%\System.Runtime.Serialization.dll

%csc% /r:"%refserialization%" ParseXml.cs

Regards, Alex
[TechBlog] http://devkids.blogspot.com

MS> I recently installed the .NET 3.0 framework (behind the time, I
MS> know), and am seeing an issue building it.
MS>
MS> Because 3.0 doesn't upgrade csc.exe, I'm still using the 2.0 csc to
MS> build things. Since the assemblies added in 3.0 aren't in the 2.0
MS> directory tree, their names need to be fully qualified, so I wind up
MS> with command lines like:
MS>
MS> csc /r:"c:\WINDOWS\Microsoft.NET\Framework\v3.0\Windows
MS> Communication Foundation"\System.Runtime.Serialization.dll
MS> ParseXml.cs
MS>
MS> Did I miss some way to simplify this, or is that just how it works?
MS>

 

[Arne Vajhøj]

Jon Skeet [C# MVP] wrote:
Out of curiosity, why don't you simply install 2008 express?
We have a mixed environment, of which .NET is only a fraction,
and
thus our build environment is command-line driven rather than
.NET-centric. Nor do I want to have to install and maintain
VS.NET
on headless machines used only to do builds.
So use MSBuild - create project/solution files with Visual Studio,
and just run MSBuild on those and let it deal with everything.
Does MSBuild integrate well with Ant? That's what drives the build
(Ant has build-in tasks to run csc, ilasm, etc.)

I would find it tempting to use nant because:
- nant supports everything you will need

As I said above, .NET is a fraction of the entire build. Ant does a
fine job of running command-line programs, and I suspect nant does a
poor one of invoking the Java compiler within its active JVM.,

True, but you can call nant from ant !!

Arne