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 2008/01/01 03:29:20 UTC

Re: Resolving GAC Installed Assemblies

This approach didn't work out as well as I hoped. I can't use the 'provided'
scope for the GAC without using a custom resolver. We will have to push all
GAC assembly to the 'system' scope.

Shane

On Dec 27, 2007 11:20 PM, Evan Worley <ev...@gmail.com> wrote:

> This seems ok to me, and also seems to require very little work on the
> NMaven side to support assembly resolution from the GAC.
>
> -Evan
>
> On Dec 27, 2007 8:02 PM, Shane Isbell <sh...@gmail.com> wrote:
>
> > I'm thinking about requiring GAC installed assemblies to have either
> > provided or system scope. If the assembly follows versionless filenames,
> > then it can use provided scope. If the assembly has a version in the
> file
> > name (standard NMaven generated assembly), then it would be required to
> > use
> > a system scope and specify the assembly path. All the GAC installed
> > assemblies would also have an implicit runtime scope, due to the nature
> of
> > the CLR and its loading rules.
> >
> > This setup would allow users that require versionless assemblies to
> first
> > do
> > a gac install and then have the assembly available for compilation.
> > Thoughts?
> >
> > Shane
> >
>

Re: Resolving GAC Installed Assemblies

Posted by Shane Isbell <sh...@gmail.com>.
The NMaven trunk now supports the system scope. It's a bit verbose to use.
Sample below.

    <dependency>
      <groupId>System.Windows.Forms</groupId>
      <artifactId>System.Windows.Forms</artifactId>
      <version>2.0.0.0</version>
      <type>dotnet:gac_msil</type>
      <scope>system</scope>
      <classifier>b77a5c561934e089</classifier>
      <systemPath>${env.GAC_ROOT
}\GAC_MSIL\System.Windows.Forms\2.0.0.0__b77a5c561934e089\System.Windows.Forms.dll</systemPath>
    </dependency>

This will work for the 2.0.x trunk, I'd like to clean it up for 2.1, where
we don't need to set the system path as this can be resolved through the
dependency metadata.

Shane


On Dec 31, 2007 7:29 PM, Shane Isbell <sh...@gmail.com> wrote:

> This approach didn't work out as well as I hoped. I can't use the
> 'provided' scope for the GAC without using a custom resolver. We will have
> to push all GAC assembly to the 'system' scope.
>
> Shane
>
>   On Dec 27, 2007 11:20 PM, Evan Worley <ev...@gmail.com> wrote:
>
> > This seems ok to me, and also seems to require very little work on the
> > NMaven side to support assembly resolution from the GAC.
> >
> > -Evan
> >
> > On Dec 27, 2007 8:02 PM, Shane Isbell <sh...@gmail.com> wrote:
> >
> > > I'm thinking about requiring GAC installed assemblies to have either
> > > provided or system scope. If the assembly follows versionless
> > filenames,
> > > then it can use provided scope. If the assembly has a version in the
> > file
> > > name (standard NMaven generated assembly), then it would be required
> > to
> > > use
> > > a system scope and specify the assembly path. All the GAC installed
> > > assemblies would also have an implicit runtime scope, due to the
> > nature of
> > > the CLR and its loading rules.
> > >
> > > This setup would allow users that require versionless assemblies to
> > first
> > > do
> > > a gac install and then have the assembly available for compilation.
> > > Thoughts?
> > >
> > > Shane
> > >
> >
>
>