<Reference
Name = "C1.Win.C1FlexGrid"
AssemblyName = "C1.Win.C1FlexGrid"
HintPath = "..\supportDlls\C1.Win.C1FlexGrid.dll"
/>The DLL in the HintPath is of version 1.1.20024.78. When I compile with VS.NET, the DLL that ends up in the bin directory is version 1.1.20024.78.
There is also an AssemblyFolder entry that looks like this:
C1Studio = C:\Program Files\ComponentOne Studio.NET\bin
In this directory is C1.Win.C1FlexGrid.dll version 2.1.20034.144. This is not the DLL we want to compile against.
If you want to revert the ordering, please wrap the assembly folder stuff with a check for the "AssemblyFolderKey = blah" attribute of the reference. AFAIK, if this attribute is missing, VS.NET ***will not*** use the AssemblyFolders for resolution.
Does this sound acceptable? It looks like with this logic, I should be able to compile my project (while keeping your resolution order intact).
Gert Driesen wrote:
Matthew,
I looked into this again, and I'm pretty sure I'm right :
The HintPath is definitely the "last resort" for VS.NET. So we should undo your change (unless you can send me a repro).
The issue you encountered was probably due to the fact that we don't yet use the path list in the ReferencesPath attribute (of the Settings node) in the .user file (the project user options) to locate assemblies. (feel free to add support for this to the solution task :-))
Gert
----- Original Message ----- From: "Matthew Mastracci" <[EMAIL PROTECTED]>
To: "Gert Driesen" <[EMAIL PROTECTED]>
Cc: "Nant-Developers (E-mail)" <[EMAIL PROTECTED]>
Sent: Tuesday, March 16, 2004 11:35 PM
Subject: [nant-dev] Re: Solution task fixes + speedups
Gert Driesen wrote:
But you actually have two different "assembly folders" : you have the assembly folder that is referenced in your project file using the "AssemblyFolderKey" attribute of the <Reference> element, eg.
...
and you have the rest of the AssemblyFolder registry keys. Perhaps
VS.NET
first checks the AssemblyFolderKey, then the HintPath and then the rest
of
the assembly folders. But I'm just guessing here.
Aha... I don't have an AssemblyFolderKey attribute on my reference - it's a direct file reference. The AssemblyFolder check was still picking it up, however.
Perhaps the order was correct as you had it, but we should skip the assembly folder check if that attribute is missing.
Even if Microsoft describes it as a last resort, it's definitely not how VS.NET does it.
I'll verify it tomorrow, and report it to MS if necessary
Cool. Thanks!
Matt.
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
