[nem-bug] [Nemerle 0000683]: Loading Nemerle.Macros.dll if it
placed in GAC
feedback at nemerle.org
feedback at nemerle.org
Sat Dec 16 12:08:11 CET 2006
The following issue has been UPDATED.
======================================================================
<http://nemerle.org/bugs/view.php?id=683>
======================================================================
Reported By: VladD2
Assigned To:
======================================================================
Project: Nemerle
Issue ID: 683
Category: Compiler
Reproducibility: always
Severity: minor
Priority: urgent
Status: new
======================================================================
Date Submitted: 05-23-2006 05:05 CEST
Last Modified: 12-16-2006 12:08 CET
======================================================================
Summary: Loading Nemerle.Macros.dll if it placed in GAC
Description:
If the Nemerle.Macros.dll (and other Nemerle assemblies) placed in GAC and
the Nemerle.Macros.dll not contain alongside with executable, the Nemerle
compiler (exactly LibrariesLoader) report:
"cannot load assembly with macros `Nemerle.Macros'"
It's occurs because assemblies in the GAC placed in separate directories:
C:\WINDOWS\assembly\GAC_MSIL\Nemerle.Compiler\0.9.3.13__5291d186334f6101\Nemerle.Compiler.dll
C:\WINDOWS\assembly\GAC_MSIL\Nemerle.Macros\0.9.3.26__5291d186334f6101\Nemerle.Macros.dll
C:\WINDOWS\assembly\GAC_MSIL\Nemerle\0.9.3.8__e080a9c724e2bfcd\Nemerle.dll
Correct way to load assembly from GAC is a specify it FullName. But I not
found way how make it in the CodeCompletionEngine.
In the attachment hack which solves a problem by means of
Assembly.LoadWithPartialName() method. It's no good. Bat better than
nothing.
Please applay this patch.
======================================================================
----------------------------------------------------------------------
VladD2 - 05-23-06 23:54
----------------------------------------------------------------------
New patch for r6327.
----------------------------------------------------------------------
nazgul - 05-24-06 12:10
----------------------------------------------------------------------
Ok, I guess this is the correct approach and it will solve all the previous
problems with loading Nemerle.Macros (in ASP.NET and now in completion
engine).
I'm not sure though if we should not include some additional information
in the "Nemerle.Macros" name, like PublicKey of Version - this would
prevent some problems with several versions of installed Nemerle, but at
the same time limit the user from "exchanging Nemerle.Macros" to his own
(and it's still a bit hackish solution).
I would go for this, but Michal, I remember you had some againsts for
this, what is your opinion?
(btw. Vlad, if you would like to get the svn access, so you can fix the
bugs yourself, please use form at https://nemerle.org/svnaccount.php).
----------------------------------------------------------------------
malekith - 05-24-06 13:27
----------------------------------------------------------------------
LoadWithPartialName is evil. You never know what will it end up loading.
Maybe it would be good idea to move CodeComplEng to separate DLL. Then it
could just reference N.M.dll during compilation and load it through some
typeof(Nemerle.Core._foreach_macro).Assembly or whatever?
I'm not really in a position to criticize here, so I'm not against that
temporary hack with LoadWithPartialName.
----------------------------------------------------------------------
nazgul - 05-24-06 13:40
----------------------------------------------------------------------
On the other hand, if we specified full signature to load,
"Nemerle.Macros.dll,Version=0.9.3,PublicKey=..." it would not "load
arbitrary assembly.
Maybe even if you used this full format, it would be possible to use just
Assembly.Load instead of PartialName (as we would give FULL name :P )
----------------------------------------------------------------------
VladD2 - 05-24-06 20:49
----------------------------------------------------------------------
> LoadWithPartialName is evil. You never know what will it end up loading.
You are right. But this hack is caused by that how you load
Nemerle.Macros.dll assembly.
> Maybe it would be good idea to move CodeComplEng to separate DLL.
It will not help. The problem in the LibrariesLoader is more exact in
LookupAssembly(). This algorithm is incompatible with GAC!
Available 2 correct way for loading assembly:
1. Load assembly from file by full path.
2. Load assembly by full name (strong name). Only this way warranty load
assembly of correct version (especially in case if assembly in GAC).
LookupAssembly () it is roundabout of these algorithms.
There can be you will use full names? But it demands that the version of
Nemerle.Macros.dll was known to the compiler or coincided with the version
of the compiler.
----------------------------------------------------------------------
nazgul - 05-24-06 21:02
----------------------------------------------------------------------
We could load Nemerle.Macros by its strong name. But I'm also not sure
about the usage of compiler, which is not placed into the GAC. Does Load /
LoadWithPartialName consider Nemerle.Macros.dll from current directory (in
fact, from ncc.exe's directory), how would it behave if there is one
version in GAC and other on disk.
If we are able to load assemblies only when they are placed in GAC, this
is not a solution... Our LookupAssembly tries to imitate what csc does -
lookup in some set of directories in search of specified assemblies. (csc
NEVER use GAC, at least this is what MS claims).
----------------------------------------------------------------------
VladD2 - 05-25-06 01:53
----------------------------------------------------------------------
csc.exe is a unmanaged application. It not need loading assembly for
itself.
Except for that the C# compiler does not find assemblies. It receives a
path to it. If assembly in a GAC and in the project specify it strong name
without <HintPath> tag in msbuild file the compiler receive path to GAC.
Exactly it occurs and in case of Nemerle.
Here a console output in VS 2005 (I use simple integration):
C:\Program Files\Nemerle\ncc.exe /no-color /nowarn:1701,1702 /no-stdlib
/define:DEBUG;TRACE /debug+ /out:obj\Debug\GacTestN.exe /target:exe
Properties\AssemblyInfo.n Main.n
/ref:C:\WINDOWS\assembly\GAC_MSIL\GacTestLib\1.0.0.0__3f9523d9b4934101\GacTestLib.dll
/ref:"C:\Program Files\Nemerle\Nemerle.dll"
/ref:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll
/ref:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.dll
/ref:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll
Pay attention to a line
/ref:C:\WINDOWS\assembly\GAC_MSIL\GacTestLib\1.0.0.0__3f9523d9b4934101\GacTestLib.dll
<Reference Include="GacTestLib, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=3f9523d9b4934101, processorArchitecture=MSIL" />
So from the compiler not required any magic.
But ncc and CompletionEngine should work independently of installed
assembly in GAC or not.
----------------------------------------------------------------------
nazgul - 05-25-06 06:56
----------------------------------------------------------------------
Of course both csc and ncc can handle strong names or full paths, but they
accept and shold accept more...
Like you can say:
csc /r:System.Data.dll /r:System.Windows.Forms.dll t.cs
and it finds assemblies in csc's directory (which is somewhere in
c:\win\Microsoft.NET/v2..../)
Also, if you have foo.dll in current directory, and type
csc /r:foo.dll t.cs
then it compiles fine - csc is also searching the current dir. You can
also extend the searched paths with /lib option:
/lib:<file list> Specify additional directories to search in
for references
http://blogs.msdn.com/grantri/archive/2004/07/08/177513.aspx
Unfortunately we can't do this easily, since ncc.exe requires Nemerle.dll
in runtime and it uses the GAC one.
----------------------------------------------------------------------
nazgul - 12-06-06 19:19
----------------------------------------------------------------------
We must consider using full/strong name of Nemerle.Macros hardcoded in
complier / overridable in ManagerClass.
This should be checked before release (if this works correctly after
placing Nemerle.Macros.dll into GAC and if we can still use compiler when
all dlls are placed in the same directory)
Issue History
Date Modified Username Field Change
======================================================================
05-23-06 05:05 VladD2 New Issue
05-23-06 05:05 VladD2 File Added: MacroLibLoading_and_ComplEng.patch
05-23-06 23:54 VladD2 Note Added: 0001311
05-23-06 23:54 VladD2 File Added: MacroLibLoading_and_ComplEng-2.patch
05-24-06 01:34 VladD2 File Added: MacroLibLoading_and_ComplEng-3.patch
05-24-06 12:10 nazgul Note Added: 0001313
05-24-06 13:27 malekith Note Added: 0001314
05-24-06 13:40 nazgul Note Added: 0001315
05-24-06 20:49 VladD2 Note Added: 0001316
05-24-06 21:02 nazgul Note Added: 0001317
05-25-06 01:53 VladD2 Note Added: 0001318
05-25-06 06:56 nazgul Note Added: 0001319
12-06-06 19:19 nazgul Note Added: 0001565
12-06-06 19:19 nazgul Priority normal => high
12-06-06 19:19 nazgul Description Updated
12-16-06 12:08 malekith Priority high => urgent
12-16-06 12:08 malekith Description Updated
======================================================================
More information about the bugs
mailing list