Non-Standard .NET 3.0 Configuration

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Non-Standard .NET 3.0 Configuration

Shane Isbell
Just a heads up. I downloaded the .NET 3.0 package and some issues I have
cropped up. .NET 3.0 contains some extensions but still uses the .NET
2.0compilers and executables (in the
v2.0 directory). This is an awkward situation for the NMaven framework to
handle because Microsoft distributes executables across two different root
directories: NMaven only has a concept of a single install root for a single
framework version (What was I thinking?).

Shane
Reply | Threaded
Open this post in threaded view
|

Re: Non-Standard .NET 3.0 Configuration

Shane Isbell
I have looked some more into the NMaven support for .NET 3.0 . The big
difference between .NET 2.0 and .NET 3.0 is the Windows Communication
Foundation (ws-* the next generation web services) support within 3.0. The
compilers are still 2.0. I can use the nmaven-settings file to point .NET
3.0 to the installRoot for 2.0, taking care of the general compiler support.


The next steps are to provide: 1) compiler support for WCF dlls and 2)
runtime support for WCF dlls - this is for the NUnit tests. I can easily
achieve WCF compiler support within the .NET 3.0 CompilerExecutable instance
by adding references to the WCF dlls: by this I mean adding the "/reference
<wcf-dll>.dll" options to the csc command.  This does not, however, solve
the runtime issue. One idea I would like to float is to have NMaven install
the WCF dlls into the local maven repository. Then NMaven can dynamically
inject the WCF dependencies, without them being explictly defined within the
pom. This allows NUnit (and the compiler) to function as is, without any
architectural changes to NMaven: I don't want to change the framework to
accommodate an odd case that should not be generalized. What are people's
thoughts on installing .NET framework dlls into the local maven repo? Any
dangers here that I am not seeing?

Shane

On 12/20/06, Shane Isbell <[hidden email]> wrote:

>
> Just a heads up. I downloaded the .NET 3.0 package and some issues I have
> cropped up. .NET 3.0 contains some extensions but still uses the .NET 2.0compilers and executables (in the
> v2.0 directory). This is an awkward situation for the NMaven framework to
> handle because Microsoft distributes executables across two different root
> directories: NMaven only has a concept of a single install root for a single
> framework version (What was I thinking?).
>
> Shane
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Non-Standard .NET 3.0 Configuration

Shane Isbell
Okay, I've added support for .NET 3.0 and merged over the branch into the
trunk. This was a bit easier than I expected. I just added the WCF dll
references to the DefaultCompiler. Since these are system level dlls, they
are in the GAC so I didn't have to worry about the WCF runtime dependencies
for NUnit.

Shane


On 12/27/06, Shane Isbell <[hidden email]> wrote:

>
> I have looked some more into the NMaven support for .NET 3.0 . The big
> difference between .NET 2.0 and .NET 3.0 is the Windows Communication
> Foundation (ws-* the next generation web services) support within 3.0. The
> compilers are still 2.0. I can use the nmaven-settings file to point .NET
> 3.0 to the installRoot for 2.0, taking care of the general compiler
> support.
>
> The next steps are to provide: 1) compiler support for WCF dlls and 2)
> runtime support for WCF dlls - this is for the NUnit tests. I can easily
> achieve WCF compiler support within the .NET 3.0 CompilerExecutable
> instance by adding references to the WCF dlls: by this I mean adding the
> "/reference <wcf-dll>.dll" options to the csc command.  This does not,
> however, solve the runtime issue. One idea I would like to float is to have
> NMaven install the WCF dlls into the local maven repository. Then NMaven can
> dynamically inject the WCF dependencies, without them being explictly
> defined within the pom. This allows NUnit (and the compiler) to function as
> is, without any architectural changes to NMaven: I don't want to change the
> framework to accommodate an odd case that should not be generalized. What
> are people's thoughts on installing .NET framework dlls into the local maven
> repo? Any dangers here that I am not seeing?
>
> Shane
>
>  On 12/20/06, Shane Isbell <[hidden email]> wrote:
> >
> > Just a heads up. I downloaded the .NET 3.0 package and some issues I
> > have cropped up. .NET 3.0 contains some extensions but still uses the
> > .NET 2.0 compilers and executables (in the v2.0 directory). This is an
> > awkward situation for the NMaven framework to handle because Microsoft
> > distributes executables across two different root directories: NMaven only
> > has a concept of a single install root for a single framework version (What
> > was I thinking?).
> >
> > Shane
> >
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Non-Standard .NET 3.0 Configuration

Dan Fabulich-2
In reply to this post by Shane Isbell
I have remarked elsewhere that the GAC serves many of the same purposes as the Maven local repo... Putting things that could/should be in the GAC in the local repo is only (at worst) redundant.

Putting .NET framework DLLs in an official remote repo is another matter entirely; I know MS allows you to redistribute the specially marked "redistributable" .NET framework installer, but I don't think you're allowed to take individual files out of there and distribute them separately. (It sounds like that won't be necessary in this case, but it's something worth investigating regardless.)

-Dan

 -----Original Message-----
From: Shane Isbell [mailto:[hidden email]]
Sent: Wednesday, December 27, 2006 08:39 AM Pacific Standard Time
To: [hidden email]
Subject: Re: Non-Standard .NET 3.0 Configuration

I have looked some more into the NMaven support for .NET 3.0 . The big
difference between .NET 2.0 and .NET 3.0 is the Windows Communication
Foundation (ws-* the next generation web services) support within 3.0. The
compilers are still 2.0. I can use the nmaven-settings file to point .NET
3.0 to the installRoot for 2.0, taking care of the general compiler support.


The next steps are to provide: 1) compiler support for WCF dlls and 2)
runtime support for WCF dlls - this is for the NUnit tests. I can easily
achieve WCF compiler support within the .NET 3.0 CompilerExecutable instance
by adding references to the WCF dlls: by this I mean adding the "/reference
<wcf-dll>.dll" options to the csc command.  This does not, however, solve
the runtime issue. One idea I would like to float is to have NMaven install
the WCF dlls into the local maven repository. Then NMaven can dynamically
inject the WCF dependencies, without them being explictly defined within the
pom. This allows NUnit (and the compiler) to function as is, without any
architectural changes to NMaven: I don't want to change the framework to
accommodate an odd case that should not be generalized. What are people's
thoughts on installing .NET framework dlls into the local maven repo? Any
dangers here that I am not seeing?

Shane

On 12/20/06, Shane Isbell <[hidden email]> wrote:

>
> Just a heads up. I downloaded the .NET 3.0 package and some issues I have
> cropped up. .NET 3.0 contains some extensions but still uses the .NET 2.0compilers and executables (in the
> v2.0 directory). This is an awkward situation for the NMaven framework to
> handle because Microsoft distributes executables across two different root
> directories: NMaven only has a concept of a single install root for a single
> framework version (What was I thinking?).
>
> Shane
>
>
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.