Missed this, sorry - yes I've seen the same here and removing gacutil from the
build side is important for the portability aspect. I'm not sure if it is
needed for NPanday.Plugin to operate correctly or not - I haven't had a chance
to figure that out. That's separate from the way it is being used in the
project importer, however.
- Brett
On 06/07/2011, at 12:22 AM, Matthias Wessendorf wrote:
> Hi,
>
> having the "gacutil" on the path, but running into "permission
> issues", on Mac (Mono).
>
> $NPANDAY_SRC/dotnet/assemblies/NPanday.Model.Pom
>
> Issuing "mvn clean install" in there, gives me this build failure:
> [INFO] [install:install {execution: default-install}]
> [INFO] NPANDAY-070-003: Found executable path for gacutil:
> /Library/Frameworks/Mono.framework/Commands
> Failure adding assembly
> /Users/matzew/Work/Apache/NPanday/trunk/dotnet/assemblies/NPanday.Model.Pom/target/NPanday.Model.Pom.dll
> to the cache: gac directories could not be created, possibly
> permission issues.
> [INFO] NPANDAY-070-003: Found executable path for gacutil:
> /Library/Frameworks/Mono.framework/Commands
> [INFO] NPANDAY-070-003: Found executable path for gacutil:
> /Library/Frameworks/Mono.framework/Commands
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] NPANDAY-1400-000: Unable to execute gacutil: Vendor null,
> frameworkVersion = null, Profile = GACUTIL
>
> Embedded error: NPANDAY-070-000: Execution Path =
> /Library/Frameworks/Mono.framework/Commands, Command = [/i,
> /Users/matzew/Work/Apache/NPanday/trunk/dotnet/assemblies/NPanday.Model.Pom/target/NPanday.Model.Pom.dll]
> NPANDAY-040-001: Could not execute: Command = /bin/sh -c cd
> /Library/Frameworks/Mono.framework/Commands && gacutil /i
> /Users/matzew/Work/Apache/NPanday/trunk/dotnet/assemblies/NPanday.Model.Pom/target/NPanday.Model.Pom.dll,
> Result = 1
>
>
>
>
> ==> Issuing it with "sudo" (sudo mvn clean install) makes it work.
>
>
> I noticed before that on Mac/Linux (with Mono) I have to use "sudo" in
> order to install DLLs to the GAC, by using the "gacutil".
>
>
> -M
>
>
> On Tue, Jul 5, 2011 at 2:18 PM, Brett Porter <[email protected]> wrote:
>> I had a go at removing it (see the newly commented code in the utility), but
>> it didn't pan out well. So for now, yes, it needs to be on the path - but I
>> hope not for long. There's a few pieces of code in there trying to figure
>> out if a reference is in the GAC from just a name that is imperfect. Another
>> thing this is needed is to use AppDomains so all the libraries aren't loaded
>> up into the addin's assembly space.
>>
>> - Brett
>>
>> On 02/07/2011, at 3:12 PM, John Fallows wrote:
>>
>>> Devs,
>>>
>>> In one of the recent releases a lot of work was done on the plugins to
>>> ensure that the environment PATH did not need to be set in order to locate
>>> various utilities such as csc.exe, etc, so I don't have them on my path any
>>> more to avoid unanticipated side effects.
>>>
>>> However, it seems that the VisualStudio ProjectImporter Engine project fails
>>> to build due to an exception in GacUtility when it is unable to locate
>>> gacutil.exe because it is not on the path.
>>>
>>> Is the PATH requirement for gacutil.exe intentional?
>>>
>>> tc,
>>> -john.
>>> --
>>>> |< Kaazing Corporation >|<
>>> John Fallows | CTO | +1.650.960.8148
>>> 444 Castro St, Suite 1100 | Mountain View, CA 94041, USA
>>
>> --
>> Brett Porter
>> [email protected]
>> http://brettporter.wordpress.com/
>> http://au.linkedin.com/in/brettporter
>>
>>
>>
>>
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
--
Brett Porter
[email protected]
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
