I have a DSL Tools solution.
I need to add a weak-named reference to this project.
Because the DSL Tools project DLL is strong-named i cannot used the weak-named DLL.
I cannot make the DLL strong-named because i cannot recompile it.
I tried to make my DSL Tools project DLL weak-named by going to the Dsl and DslPackage project properties and unchecked the option "Sign the assembly" in the Sigining tab.
Then i compile it.
The error list gives the following error
"gacutil.exe" exited with code 1
Looking at the VS2005 output window i see gacutil is being called
C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin\gacutil.exe -nologo -i "C:\Academy\ResearchAndDevelopment\FrontendGenerator\DslPackage\bin\Debug\vantyx.FEGenerator.DslPackage.dll"
After that i used the command prompt and the gacutil.exe error displays as this:
Z:\>"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin\gacutil.exe" -nologo -i "C:\Academy\ResearchAndDevelopment\FrontendGenerator\DslPackage\bin\Debug\vantyx.FEGenerator.DslPackage.dll"
Failure adding assembly to the cache: Attempt to install an assembly without a strong name
I don't know why and how gacutil.exe is being called.
I looked at the project and solution properties and there is no option configured to call gacutil.exe.
I even looked inside every file for "gacutil.exe" but i found nothing.
What i really want is to be able to use the weak-named DLL that i cannot make strong-named.
As a result of this, i've been trying to make my DSL Tools DLL weak-named but i can't.
Any help on how i can workaround this?
Many thanks in advance,
Luís Filipe
Using runtime binding with reflexion is a good solution and works. The other solution I've implemented besides that one is to launch a separate AppDomain and have that AppDomain doing the loading of the assembly and running whatever methods you want. The downside of this approach is the extra complexity and performance. One really has to know what he is doing as he is in practice launching a separate .net application in Visual Studio's process space. The upside is that with some care, you can get type safety all the way.
With the exception of the answer written above,
All add-ins for Visual Studio must be strong-named.
One may workaround some of the issues by loading the assembly on run-time and using reflection to invoke methods.
Regards,
Luís
Related
There is a bug in the WiX plugin for Visual Studio where file locks on referenced DLLs are not properly released. Therefore, you have to restart Visual Studio every time you want to recompile a custom extension DLL or any assembly referenced by it.
This is a known bug, but the issue was closed because there seems to be a solution / workaround:
You can force the WiX .exes to run out-of-process to avoid the lock
MSBuild has.
I don't understand how to achieve this. I checked...
the properties of my WiX setup project
the properties of the extension assembly (C# class library)
all Visual Studio settings
the available command line arguments of candle.exe
...but did not find anything. What am I missing? How do I apply this workaround?
I'm using WiX 3.10 and Visual Studio 2013.
The example that I've seen several times around the web is to add <RunWixToolsOutOfProc>true</RunWixToolsOutOfProc> to the Wix Installer's project file within a property group. Unfortunately, documentation of this feature has thus far eluded me.
I'm having a hard time trying to build a F# project in Visual Studio that has dependencies downloaded with Paket. It raises several of the following errors (with different dlls each time):
Could not resolve this reference. Could not locate the assembly "XPlot.Plotly.dll". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. (Code=MSB3245)
For this very example, visual studio adds the option -r:C:\projects\StarWars-social-network-master\packages\XPlot.Plotly\lib\net45\XPlot.Plotly.dll. The file actually exists in my filesystem, so I don't know what I am doing wrong. Can anyone point me to a workaround?
Thank you.
From the directory name, I guess you're looking at Evelina Gabasova's Star Wars network analysis.
As far as I can tell, the project uses F# Script files and so you do not need to compile it at all. It is designed to be used with F# Interactive. Once you open the project, you can look at the individual script files *.fsx, select blocks of code and run them interactively - If you are using Visual Studio, this is done using Alt+Enter - other editors use either this or Ctrl+Enter (Xamarin Studio).
Many F# data analysis scripts follow this pattern - you're not really building a project that needs to be compiled and executed as a whole, so running bits of code from script files immediately makes a lot more sense in this context.
I am creatinig Managed Extensibility Framework extensions for some program. That program uses dll files witch i create. I dont have visual studio project of that program, but i have that program. I can run these extensions using that program, but cant debug them properly.
Is it possible to use visual studio debugger to debug my code?
I found solution to this, thanks!
I found solution to this by my self, but thanks for sugestions.
I can use that app for which i am creating this extension, class libary project.
I press properties on project, then select debug tab and set "start external programm" an set it o that main app. then i press f5 and that app starts and when it uses my extension i can debug it using visual studio debugger. And i forgot to tell that i am creating this in C#.
http://msdn.microsoft.com/en-us/library/68c8335t.aspx
I believe what you are looking for can be found here:
http://msdn.microsoft.com/en-us/library/0bxe8ytt.aspx
According to this article, you could use the "Add Existing Project" dialog in you solution (for your DLL) to add the executable that you do not have the solution for. Because you are using MEF, it might get a bit tricky and you might want to create a new solution for debugging instead. However, this seems to be the general way to handle your situation. Since you have the source code for your DLL, I believe it should allow you to step through your code fully at the very least.
Note: You will need to make sure you have Visual C++ installed in your development environment.
If you are trying to debug the assembly code, then you can use the technique discussed by #BiggsTRC, if you are simply trying to identify why parts aren't being loaded, you could consider looking at the Composition Analysis Tool (mefx). This is a command-line tool for analysing a set of parts and finding out where failures may occur during composition.
I'm trying to set up some build scripts for continuous integration and I'm finding something weird.
My solution compiles fine from Visual Studio 2010, but fails with an error when I build the exact same thing from the command line with MSBuild.
Here's the error I get from the commandline build.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.WinFX.targets(269,9):
error MC1000: Unknown build error,
'Cannot resolve dependency to assembly 'Microsoft.Windows.Design.Extensibility, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.'
[C:\Dev\Market Watch\src\Console\MarketWatch.Console\Rbnz.MarketWatch.Console.csproj]
I've checked through all my source code for references to Microsoft.Windows.Design.Extensibility and haven't found any at all. I've also checked all the binaries we reference from this project, including some DevExpress libraries.
My MSBuild commandline looks like this:
MsBuild.exe c:\Dev\MarketWatch\src\Capture\Capture.sln
/t:rebuild
/verbosity:quiet
/filelogger
/fileloggerparameters:LogFile=c:\Dev\MarketWatch\build\Logs\capture.msbuild.log
Is there something missing that I should include on the MsBuild commandline to make commandline builds work just the same as those run by Visual Studio?
Update 14/4
I'm getting these errors despite running the build script from a Visual Studio command prompt.
I hope you solved the problem, but for future reference:
I just had the same problem, and it comes from DevExpress '.design' assemblies. You're actually not supposed to reference those in your project. Remove all references to DevExpress assemblies ending with '.design' and it should work.
You should initialize paths to find assemblies, tools and so on. Call vcvarsall.bat before calling msbuild:
call "%ProgramFiles%\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x64
Or open VS2010 command line console and call your script from it. Both actions has the same effect.
EDIT: I couldn't understand one thing - google for your question says that you use Reflection in a wrong way, and one of possible solutions is described here. Am I right?
I recently encountered the same issue.
The Error was thrown on our VSTS-BuildAgent.
After following all advices from Devexpress sites (including Project-Upgrade), the Error was still there.
To be honest, we are mixing WinForms and WPF for a smooth migration from Winforms to WPF, so basically not an everyday-problem.
Anyway, i was able to fix this, by adding all needed references to WPF-Project again, even if they are all already referenced in the Start-Project, which is Winforms.
After this move, the BuildAgent was able to succeed the Build.
I'm working on Windows 7 with Visual Studio 2008.
I have a .NET assembly that makes calls into a native DLL with P/Invoke. I have set up a separate .NET unit test project in my Visual Studio solution that tests the assembly by making various calls into it. However, when the unit test makes a call into the assembly, and the assembly makes a call using P/Invoke, it can't find the native DLL.
When I write a standalone .NET console application, there is no problem. The assembly can use P/Invoke and find the DLL successfully.
I can make the unit test work by calling LoadLibrary with the absolute path of the DLL before using the assembly. However, this approach is ugly and requires an absolute path - which will be problematic for other users.
In short, my question is - how can I specify or amend the DLL search path that is being used when a Visual Studio unit test is being executed?
Any help will be greatly appreciated.
Regards,
Dan
It sounds like the problem is that your native DLL is not being deployed with your unit test DLLs. This is not an uncommon problem since managed DLL's have no reference to native ones in metadata and hence deployment packages don't know to deploy them.
The most appropriate solution is to fix deployment as opposed to changing the DLL search paths. This is a unit test specific problem though. Can you tell us what framework you're using so we can help you out?
If you are using the Visual Studio 2008 integrated testing framework, you should check out the DeploymentItemAttribute Class
Basically you just decorate your test method with this attribute and it automatically copies the deployment item into the output directory before the test executes. You can even copy a whole tree of dependencies using this. It supports variable expansion and relative paths.
Also please see How to: Configure Test Deployment for more generalized information on VS2008 test deployment.
My solution was adding a post build command to my test project as follows:
xcopy /Y /S "$(SolutionDir)\ShredLibraries\*" "$(TargetDir)"
this is explained in msdn docs:
https://msdn.microsoft.com/en-us/library/ms182475.aspx