Deploying Microsoft framework dlls to an internal remote repo

[Wendy Smoak-3]

Should it be necessary to put the Microsoft framework dlls in a remote
repository, or is NMaven supposed to find them in (for example)
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 ?

We need to be able to use the 'Add Maven Artifact' feature of the VS
Addin, and see the framework dlls so they can be added to the project.
 Currently it looks like it's only going to display things from the
local and remote repositories.

Any thoughts on what the groupId should be?  I'm leaning towards
<groupId>Microsoft.Net.Framework</groupId> because they come from the
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 directory.  The version
number is easy, at least. :)

--
Wendy

[Shane Isbell]

On Tue, May 27, 2008 at 2:14 PM, Wendy Smoak <wsmoak@...> wrote:

> Should it be necessary to put the Microsoft framework dlls in a remote
> repository, or is NMaven supposed to find them in (for example)
> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 ?
>
To the best of my knowledge, the .NET framework license prohibits
redistribution of the framework libraries.

Shane

>
>
> We need to be able to use the 'Add Maven Artifact' feature of the VS
> Addin, and see the framework dlls so they can be added to the project.
>  Currently it looks like it's only going to display things from the
> local and remote repositories.
>
> Any thoughts on what the groupId should be?  I'm leaning towards
> <groupId>Microsoft.Net.Framework</groupId> because they come from the
> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 directory.  The version
> number is easy, at least. :)
>
> --
> Wendy
>

[Shane Isbell]

On Tue, May 27, 2008 at 2:14 PM, Wendy Smoak <wsmoak@...> wrote:

> Should it be necessary to put the Microsoft framework dlls in a remote
> repository, or is NMaven supposed to find them in (for example)
> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 ?
>
> We need to be able to use the 'Add Maven Artifact' feature of the VS
> Addin, and see the framework dlls so they can be added to the project.
>  Currently it looks like it's only going to display things from the
> local and remote repositories.

This is intentional because you can use the standard VS add artifacts form
for adding of references from the GAC.

>
>
> Any thoughts on what the groupId should be?  I'm leaning towards
> <groupId>Microsoft.Net.Framework</groupId> because they come from the
> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 directory.  The version
> number is easy, at least. :)



>
>
> --
> Wendy
>

[Wendy Smoak-3]

On Wed, May 28, 2008 at 8:43 AM, Shane Isbell <shane.isbell@...> wrote:

>> Should it be necessary to put the Microsoft framework dlls in a remote
>> repository, or is NMaven supposed to find them in (for example)
>> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 ?
>>
> To the best of my knowledge, the .NET framework license prohibits
> redistribution of the framework libraries.

Apparently the licensing thing has been worked out by the relevant
parties-- so assume it's not an issue for the sake of discussion.
(And it's a private internal repository in any case.)

Even so, now is the time to set the convention for the groupId and
artifactIds by putting poms into the repository without the dlls--
like we did with the Sun jars for Java builds even though the license
prohibited putting the jars in the central repo.

So... does Microsoft.NET.Framework sound okay for a groupId?

--
Wendy




--
Wendy

[Wendy Smoak-3]

On Wed, May 28, 2008 at 8:48 AM, Shane Isbell <shane.isbell@...> wrote:

>> We need to be able to use the 'Add Maven Artifact' feature of the VS
>> Addin, and see the framework dlls so they can be added to the project.
>>  Currently it looks like it's only going to display things from the
>> local and remote repositories.
>
> This is intentional because you can use the standard VS add artifacts form
> for adding of references from the GAC.

But then the pom does not stay in sync with the solution file.
IM(limited)E, the only way both of them get updated is with 'Add Maven
Artifact'.

I'm still confused about when you *need* to add a dependency to the
pom (and/or reference to the solution) though, which drives the "what
things need to be in the remote repository" question.

With Java, you don't have to add pom dependencies for things like
java.util.LinkedHashSet, just an import statement.  How does that
compare to .NET?  Is everything in the
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 directory supposed to
automatically be available when compiling with 'mvn install'? How
about when compiling within VS?

Thanks,
--
Wendy

[Shane Isbell]

On Wed, May 28, 2008 at 9:00 AM, Wendy Smoak <wsmoak@...> wrote:

> On Wed, May 28, 2008 at 8:48 AM, Shane Isbell <shane.isbell@...>
> wrote:
>
> >> We need to be able to use the 'Add Maven Artifact' feature of the VS
> >> Addin, and see the framework dlls so they can be added to the project.
> >>  Currently it looks like it's only going to display things from the
> >> local and remote repositories.
> >
> > This is intentional because you can use the standard VS add artifacts
> form
> > for adding of references from the GAC.
>
> But then the pom does not stay in sync with the solution file.
> IM(limited)E, the only way both of them get updated is with 'Add Maven
> Artifact'.

I checked the code. It handles removing of dependencies from the pom using
the standard VS controls; adding functionality still needs to be coded.

>
>
> I'm still confused about when you *need* to add a dependency to the
> pom (and/or reference to the solution) though, which drives the "what
> things need to be in the remote repository" question.
>
> With Java, you don't have to add pom dependencies for things like
> java.util.LinkedHashSet, just an import statement.  How does that
> compare to .NET?  Is everything in the
> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 directory supposed to
> automatically be available when compiling with 'mvn install'?

There is a bootstrap file:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\csc.rsp that contains all the
included references in a standard csc/mvn compile. VS doesn't use the
csc.rsp file for its compiles and you will need to explicitly add the
references yourself.

Shane


> How
> about when compiling within VS?
>
> Thanks,
> --
> Wendy
>

[Wendy Smoak-3]

On Wed, May 28, 2008 at 9:31 AM, Shane Isbell <shane.isbell@...> wrote:
> On Wed, May 28, 2008 at 9:00 AM, Wendy Smoak <wsmoak@...> wrote:

>> > This is intentional because you can use the standard VS add artifacts
>> form
>> > for adding of references from the GAC.
>>
>> But then the pom does not stay in sync with the solution file.
>> IM(limited)E, the only way both of them get updated is with 'Add Maven
>> Artifact'.
>
> I checked the code. It handles removing of dependencies from the pom using
> the standard VS controls; adding functionality still needs to be coded.

Interesting.  If you use the standard VS "Add Reference," would it be
a system scoped dependency, given that you're not picking something
from a Maven repository?  (And how will that affect portability?)

>> I'm still confused about when you *need* to add a dependency to the
>> pom (and/or reference to the solution) though, which drives the "what
>> things need to be in the remote repository" question.

> There is a bootstrap file:
> C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\csc.rsp that contains all the
> included references in a standard csc/mvn compile. VS doesn't use the
> csc.rsp file for its compiles and you will need to explicitly add the
> references yourself.

So... that sounds like it would be appropriate to add a reference in
Visual Studio that does *not* need to be in the pom, because the
command-line csc compiler would already know about it.  Correct?

Thanks for your patience. :)

--
Wendy

[Shane Isbell]

On Wed, May 28, 2008 at 1:39 PM, Wendy Smoak <wsmoak@...> wrote:

> On Wed, May 28, 2008 at 9:31 AM, Shane Isbell <shane.isbell@...>
> wrote:
> > On Wed, May 28, 2008 at 9:00 AM, Wendy Smoak <wsmoak@...> wrote:
>
> >> > This is intentional because you can use the standard VS add artifacts
> >> form
> >> > for adding of references from the GAC.
> >>
> >> But then the pom does not stay in sync with the solution file.
> >> IM(limited)E, the only way both of them get updated is with 'Add Maven
> >> Artifact'.
> >
> > I checked the code. It handles removing of dependencies from the pom
> using
> > the standard VS controls; adding functionality still needs to be coded.
>
> Interesting.  If you use the standard VS "Add Reference," would it be
> a system scoped dependency, given that you're not picking something
> from a Maven repository?  (And how will that affect portability?)

The GAC directory structure is roughly equivalent to maven repo. In 0.14, if
you specify dependency with type=GAC then it will be added to the build.
This is fully portable for any assemblies included within the .NET
framework, as they will all be installed into the GAC,

>
> >> I'm still confused about when you *need* to add a dependency to the
> >> pom (and/or reference to the solution) though, which drives the "what
> >> things need to be in the remote repository" question.
>
> > There is a bootstrap file:
> > C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\csc.rsp that contains all
> the
> > included references in a standard csc/mvn compile. VS doesn't use the
> > csc.rsp file for its compiles and you will need to explicitly add the
> > references yourself.
>
> So... that sounds like it would be appropriate to add a reference in
> Visual Studio that does *not* need to be in the pom, because the
> command-line csc compiler would already know about it.  Correct?

correct

>
>
> Thanks for your patience. :)
>
> --
> Wendy
>

[Brian E Fox]

>So... does Microsoft.NET.Framework sound okay for a groupId?
I would prefer com.microsoft.dotnet.framework

[Shane Isbell]

When the VS project files are created, we need to be able to specify the
default namespace for new classes. This must be inferred either through the
groupId or the artifactId.

Typically, for .NET projects, the artifact name is something like:
<Company>.<Project> or
<Company>.<Department>.<Project> or most commonly
<Project>.<Module>

If this artifactId convention matches what you want for a namespace, you can
give whatever groupId you want.

Personally I prefer the standard maven group id, like we did for NUnit.
Since we are signing and releasing the artifact, we use our own groupId.
http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/dotnet/NUnit.Framework/

This is cleaner organization for those projects that have both Java and .NET
artifacts, otherwise we end up with the same group ids, one capitalized and
one not.

Shane

On Fri, May 30, 2008 at 5:56 AM, Brian E. Fox <brianf@...>
wrote:

>
> >So... does Microsoft.NET.Framework sound okay for a groupId?
> I would prefer com.microsoft.dotnet.framework
>
>

[Wendy Smoak-3]

On Fri, May 30, 2008 at 10:36 AM, Shane Isbell <shane.isbell@...> wrote:

> Personally I prefer the standard maven group id, like we did for NUnit.
> Since we are signing and releasing the artifact, we use our own groupId.
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/dotnet/NUnit.Framework/

We're not signing these, just deploying the framework dlls as-is.

So, com.microsoft.dotnet.framework seems to fit better.  (Thanks, Brian.)

We're also switching to version 2.0.0.0 instead of 2.0.50727.
Apparently the former is the version of the dlls themselves, while the
latter is the overall framework version.

--
Wendy