Remote Gac returns 9

Nov 6, 2008 at 9:09 PM
Where is the output from the LogTaskMessage() calls I see in the source code? I'm not seeing them in the Build Output window.
Coordinator
Nov 6, 2008 at 9:15 PM
Can you post a sample of the task you are using.
Nov 6, 2008 at 9:20 PM

The task calls I’m making are:

<MSBuild.ExtensionPack.FileSystem.Folder TaskAction="RemoveContent" Path="$(TargetCommonContentPath)" ContinueOnError="true" />

<MSBuild.ExtensionPack.Framework.Gac MachineName="$(Machinename)" TaskAction="AddAssembly" AssemblyPath="$(OutputPath)$(AssemblyName).dll" RemoteAssemblyPath="$(TargetGlobalAssemblyPath)\$(AssemblyName).dll" Force="true" ContinueOnError="true" />

I’m not sure the RemoveContent call is even running. I haven’t tested much yet.

I definitely see the assembly being copied over to the remote machine, but the remote GAC is not showing the new timestamp like the actual dll shows.

Since neither are showing any entries in the Build Output window, but the dll is making it to the remote machine on the AddAssembly call, I assumed it must be writing the log entries somewhere else.

Coordinator
Nov 6, 2008 at 9:29 PM
That's odd. You havent set a SuppressTaskMessages environment variable to true have you? What do you get if you run it with /v:diag. Are you using the latest code from codeplex?
Nov 6, 2008 at 9:32 PM
Edited Nov 6, 2008 at 9:59 PM

For completeness, I am running from the newest build, but had a little trouble getting it to compile. I needed the remote assembly gac fix, but the Framework project had an error about the COMAdmin interop and delayed signing. What I did to get it to compile was uncheck the “Sign the Assembly” box on the Framework project and compile that one alone.

 

Since the logging looks to be a com interop call, I’m betting that’s it. So, if I’m right, that leaves me with my original problem of delay signing with the reference to COMAdmin.

 

That error was this:

 

COMAdmin : error MSB3295: Failed to load an assembly. Please make sure you have disabled strong name verification for your public key if you want to generate delay signed wrappers. Could not load file or assembly 'Interop.COMAdmin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=10d297e8e737fe34' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)

Done building project "Framework.csproj" -- FAILED.

Coordinator
Nov 6, 2008 at 9:38 PM
run this from a .net command prompt and you can compile delay signed.

sn.exe -Vr *,10d297e8e737fe34

Though that's not the issue. can you run with /v:diag and post the log.


Nov 6, 2008 at 10:03 PM

You’re right, the delayed signing thing wasn’t it. My problem was VS.NET build verbosity was too low. Here’s a sample output from the remote assembly gac task I referenced before.

Target "AfterBuild" in file "C:\work\sc_dev_build\Projects\xxx\xxx\xxx.csproj":

Task "MSBuild.ExtensionPack.Framework.Gac"

GACing Assembly: \\xxx\Projects\GlobalAssemblies\xxx.dll on Remote Server: xxx

Copying Assembly from: C:\work\sc_dev_build\Projects\xxx\xxx\bin\Dev\xxx.dll to: \\xxx\Projects\GlobalAssemblies\xxx.dll

Deleting Remote Assembly: \\xxx\Projects\GlobalAssemblies\xxx.dll

ManagementScope Set: \\xxx\root\cimv2

Process returned: 9

Process ID:

Done executing task "MSBuild.ExtensionPack.Framework.Gac".

Done building target "AfterBuild" in project "xxx.csproj".

Now I just have to figure out what Process Returned: 9 means.

Coordinator
Nov 6, 2008 at 11:03 PM
I'll have to test this tomorrow, but I'm guessing it has something to do with the share. can you try copying to an admin path rather.

i.e. instead of \\xxx\Projects\GlobalAssemblies\xxx.dll try \\yourremoteserver\c$\Projects\GlobalAssemblies\xxx.dll

That's the way I've tested it. I'll have to look at share support. Let me know if that works.

Mike
Coordinator
Nov 7, 2008 at 9:45 AM
Hi Ryan

I've managed to repro your error. They key was 'Process ID:'. This indicates that the call to gacutil on the remote server didn't create a process. I've updated the documentation to clarify

 

/// <summary>

 

 

/// Sets the remote path of the assembly. Note that gacutil.exe must exist on the remote server and be in it's Path environment variable

 

 

/// </summary>

 

 

public string RemoteAssemblyPath { get; set; }

 

Once you have gacutil setup, your solution should work. I have tested the task using a share rather than admin path and it works fine. I'm changing a few things in the task to make the logging better and to report / error better on the return codes.

Mike

Nov 7, 2008 at 2:08 PM

Gacutil.exe on the remote server, in the PATH, is exactly right. I guess I shouldn’t assume what’s in the Framework, and what’s in the SDK.

Thanks for all your help. You and your team get a ringing endorsement from me, that’s for sure!

Jul 2, 2009 at 3:04 PM

Is the requirement for GACUTIL.EXE to be in the server's path variable a WMI requirement or would it be possible to specify a full path to GACUTIL.EXE.

Thanks and great work!

Tom

Coordinator
Jul 3, 2009 at 9:13 AM

Hi

Its required for the WMI call. There is currently no support to specify the path. If this is somehting you need, can you describe your situation.

Thanks

Mike

 

Jan 5, 2012 at 10:45 AM

On the off chance that anyone's still reading, I'm having the same problem here.  I've made sure the directory with gacutil.exe (.net 4.0 version) is in the path, but it's still giving returncode 9.  I've tried playing about with PowerShell and can reproduce a returnvalue of 9 when attempting to run gacutil.exe.  Using calc.exe works, so it's not WMI.

Would the machine need to be rebooted to make sure it gets picked up?

Coordinator
Jan 31, 2012 at 4:32 PM

You may need a reboot. It's worth trying.

 

Mike