Cobra Forums

GAC = Global Assembly Cache. It's essentially the system wide storage for shared .dll's. The idea here is to get Cobra.Lang.dll put in there and then change the -embed-run-time option to default to "false" thereby speeding up compilation.

Here's what I did:

* Reviewed http://support.microsoft.com/kb/815808

* Brought up the command line prompt for the VS 2005 tools.

* Created a key with this command:

sn -k CobraGAC.snk

* Added this to CobraLang.cobra: but then got a warning that I should use a command line option instead of an assembly attribute to sign an assembly. So I removed it, and did this:

cobra -bsl -v -key-file:CobraGAC.snk

* And installed the resulting DLL to the GAC with:

gacutil -I Cobra.Lang.dll

* And verified it was there by listing it with:

gacutil /l Cobra.Lang

* I then deleted the Cobra.Lang.dll in the current directory and tried it out:

cobra -ert:no -c hello

* But it doesn't work:

error: Metadata file "Cobra.Lang.dll" could not be found

* I tried again with verbosity cranked up:

cobra -ert:no -v:2 -c hello

Apparently, Cobra is able to locate and read the DLL and to generate code. It's the C# compilation that generates the error message.

* Reissuing with the C# compilation line gives the error message again. Axing the ".dll" of the "/r:Cobra.Lang.dll" gives the error message as well.

* I tried bypassing the CSharpCodeProvider, just to try something different, with:

cobra -ert:no -v:2 -sharp-compiler:"C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\csc.exe" -c hello

but got the same error message.

This was all done in a clean workspace.


So Cobra can seemingly locate the DLL from the GAC and read its contents. But C# compilation of the generated code chokes trying to read it regardless of whether we go through the code provider or invoke the compiler as an external command.

Any ideas?

-Chuck

Just guessing randomly
but theres not an additional piece of random line noise (C# cmdline option) you need to give to the c# compiler to tell it to
use the GAC (more/better/different than it does by default) is there ?

Sounds like the c# compiler uses/looks in the cwd (or its own search path that includes that) for dependencies normally
but it needs to be prodded to use the GAC (??)
either a option or some magic entry specified in however you augment its library/dependencies search path ???

As far as i remember to put a dll in GAC the syntax is:
gacutil.exe /if filename.dll
HTH.

hopscc, there's no special flag to tell csc to use the GAC

relez, the "f" is to force an install if the assembly is already in the GAC. I tried it anyway, but no effect.

Finally, I found an interesting note at http://www.grimes.demon.co.uk/workshops/fusWSFour.htm

Basically, the metadata for the assembly does not go for the ride when you install into the GAC. So the C# compiler needs the original DLL, which it looks for in the current path or in the .NET framework directory. I think it will also check /lib paths.

I wonder if this means that when Cobra read the Cobra.Lang.dll from the GAC, it didn't get any meaningful metadata.

So I got a basic test working where I left the Cobra.Lang.dll available in the current directory (MyWorkspace\Source\) and compiled like so:

cobra -ert:no hello

And then I move hello.exe to a different directory where I was able to run it despite there not being a Cobra.Lang.dll in the same directory.

Assuming the /lib option works out then, the plan is to add /lib to the args passed to csc so it can find Cobra.Lang.dll (which is always next door to the compiler) and make -ert:no the default.

I think we'll reserve version 0.0.1 for the Snapshot compiler and version 0.0.2 for the Source compiler. Obviously, we'll use 0.8.0 for release 0.8.0, etc.

This will reduce compilation time, reduce executable size and allow us to grow the Cobra standard library without any serious overhead.

There is still more work to do to get this finalized, but I think I'm over the hump now. Thanks for your ideas.

Correction: Metadata does go for the ride, otherwise System.Reflection calls wouldn't work. I don't know why C# needs the original .dll which is even the same number of bytes. But I have it working now, and that's enough.

I'll be making a separate post about a new installer I wrote. If you want to see how the GAC is handled, you can read the code for it. Or you can just blow off the details and simply enjoy using it.