You are viewing a plain text version of this content. The canonical link for it is here.
Posted to nmaven-dev@incubator.apache.org by Shane Isbell <sh...@gmail.com> on 2006/12/20 18:34:06 UTC

Non-Standard .NET 3.0 Configuration

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

Re: Non-Standard .NET 3.0 Configuration

Posted by Shane Isbell <sh...@gmail.com>.
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 <sh...@gmail.com> 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 <sh...@gmail.com> 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
> >
> >
>
>

Re: Non-Standard .NET 3.0 Configuration

Posted by Shane Isbell <sh...@gmail.com>.
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 <sh...@gmail.com> 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
>
>