Cannot get DLLReferencePath to take effect

Nov 16, 2007 at 8:55 AM
I need to point the DLLReferencePath to a specific folder. In my reference folder I for example have Microsoft.SharePoint.ApplicationPages.dll. But independently if I put DLLReferencePath in the config file or on the command line I cannot get it to take effect. Is there anything special about specifying it?

As a work around I have copied all my referenced dlls to the solution folder but that is not a good looking solution.

Also, after I upgraded to the latest version WSPBuilder no longer writes out an error message to the console. It does not generate any error message at all. The only way to know that it failed is to check that the .wsp file was not created.

// Mats
Coordinator
Nov 16, 2007 at 9:21 AM
The WSPBuilder do not include DLL files from Microsoft.SharePoint, this is hard coded into the program. And I can not come up with any reason why WSPBuilder should include Microsoft.SharePoint dlls. All the Microsoft.SharePoint DLL's are on the server that you deploy to already!. However I will check DLLReferencePath parameter,

For writing out more information use the -Tracelevel parameter.

/keutmann


boisen wrote:
I need to point the DLLReferencePath to a specific folder. In my reference folder I for example have Microsoft.SharePoint.ApplicationPages.dll. But independently if I put DLLReferencePath in the config file or on the command line I cannot get it to take effect. Is there anything special about specifying it?

As a work around I have copied all my referenced dlls to the solution folder but that is not a good looking solution.

Also, after I upgraded to the latest version WSPBuilder no longer writes out an error message to the console. It does not generate any error message at all. The only way to know that it failed is to check that the .wsp file was not created.

// Mats

Nov 16, 2007 at 11:10 AM
First, let me start by saying that WSPBuilder is a great tools. Many thanks for creating it. We use in the core of our deployment process.

Maybe I was a bit unclear on my problem statement. I specify the DLLReferencePath parameter to point to a folder where we have assemblies that contain classes that we have inherited our classes from. Those dlls are deployed through other means but they must be located when WSPBuilder runs otherwise the wsp-generation fails. Since those dlls are in another folder I would like to specify "DLLReferencePath ..\..\..\References" but I cannot get that to take effect. WSPBuilder still seems to be looking for reference dlls in the solution folder.

When WSPBuilder fails to generate the safe control list because of this no wsp-file is created but I do not get an error message. My trace section looks like this
<system.diagnostics>
<switches>
<add name="TraceLevelSwitch" value="4" />
</switches>
<trace autoflush="true" indentsize="4">
<listeners>
<add name="ConfigConsoleListener" type="System.Diagnostics.ConsoleTraceListener" />
<add name="TextFileListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="WSPBuilder.log" />
</listeners>
</trace>
</system.diagnostics>

I added the two listeners to see if I could get some response. But I do not get any messages from WSPBuilder what so ever!?

// Mats
Coordinator
Dec 6, 2007 at 3:50 PM
The DLLReferencePath have been solved in version 0.9.7.1205.
Feb 27, 2008 at 5:07 AM
Edited Feb 27, 2008 at 5:07 AM
No it's not - I have spent the past two hours trying to figure out how to get this tool to recognize Microsoft.SharePoint.ApplicationPages.Administration.dll and it won't. I had to play around with it to recognize Microsoft.SharePoint.ApplicationPages - I finally got it to work by renaming the folder that contained the solution - somehow that got it working again. I'm running version 1.0.0
Feb 27, 2008 at 5:19 AM
so is there a limit on the number of assemblies that this tool can resolve? I have the two that I mentioned above - one of them resolves, and the other doesn't - can someone please explain this behavior? I really don't have the time to continue trouble-shooting this issue.
Feb 27, 2008 at 5:33 AM
There are some issues with this tool - I had to recreate this project and add all the files manually before I could get WSPBuilder to recognize both .dll's - frustrating.
Feb 27, 2008 at 5:49 AM
Nevermind - I didn't resolve the issue after all - when I rebuilt the solution after recreating my project and references, it built fine and the .wsp was created - then I realized that I did not sign the assembly, so I signed it, rebuilt it, and attempted to create the wsp and it failed again. So there is some issue with strong naming with the Microsoft.SharePoint.ApplicationPages.Administration.dll, or strong naming with multiple assemblies, who knows - it doesn't work, though.

Please try on your own to verify - my mistake was not buckling down to learn how to create solutions on my own - I cannot afford to troubleshoot this tool any longer.
Coordinator
Feb 27, 2008 at 7:49 PM
I know that there are some problems with resolving assemblies that are referenced from other assemblies. The reason to this is because of the way Assembly.Load() method works. I have now got a version of Mono.Cecil that works properly on security reflection, so I plan to implement this into WSPBuilder to solve the reference assembly problem. The problem with assemblies that are not strong named should not be a problem, but I'll look into this.
The WSPBuilder should be able to resolve the Microsoft.SharePoint.ApplicationPages.Administration.dll assembly, but this again will not be a problem with the Mono.Cecil solution. Please wait for the next version of WSPBuilder.

/keutmann



satarter wrote:
Nevermind - I didn't resolve the issue after all - when I rebuilt the solution after recreating my project and references, it built fine and the .wsp was created - then I realized that I did not sign the assembly, so I signed it, rebuilt it, and attempted to create the wsp and it failed again. So there is some issue with strong naming with the Microsoft.SharePoint.ApplicationPages.Administration.dll, or strong naming with multiple assemblies, who knows - it doesn't work, though.

Please try on your own to verify - my mistake was not buckling down to learn how to create solutions on my own - I cannot afford to troubleshoot this tool any longer.