I have debug and release dll from some library that weight a ton and updated from time to time. Debug and Release version .dll have the same name, without d.dll.
Is there a way I can add them to project without copying them into project folder?
I tried setting folder in Debugging->Environment, didnt worked. I added to Path system environment variable, it worked. But this way I have to change variable to whether Im building Release of Debug. I created my own env variable like LIB_DEBUG, but I do not know where to add it in Visual Studio for it to be able to grab dll.
There are multiple ways to attack this, but typically you have a $(Platform)$(Configuration) macro
If you have a DLL "foo.dll" and there are two copies:
../Debug/foo.dll
../Release/foo.dll
Then you can set the properties for Library Directories to be
../$(Configuration)/foo.dll
And the linker will look in DEBUG for the DEBUG builds and Release for the Release Builds.
There is also an EXECUTEABLE path, but this only works within Visual Studio. For runtime you will either need to distribute foo.dll with myfoo.exe in the same directory, or update the PATH enviornment variable to be either ../Debug/foo.dll or ../Release/foo.dll to avoid DLL Hell.
You could have a post build step that copies from
copy ../$(Configuration)/foo.dll $(TargetDir)
This will make sure the correct DLL is in the same location as the *.exe and this is the first place Windows looks for DLL's at runtime.
I have C# and C++ projects in Visual Studio's solution.
How to make them build into one common folder?
In C++ projects Output Directory is set to $(SolutionDir)$(Platform)\$(Configuration)\:
But in C# projects it just says bin\release\:
And outputs into $(ProjectDir)bin\release as it usually does in C# projects.
When in C# projects I set Output path to $(SolutionDir)$(Platform)\$(Configuration)\:
It creates folder named $(SolutionDir)$(Platform) inside its project folder:
I would like files from all of my projects to be output to $(SolutionDir)bin\$(Platform)\$(Configuration)\. So on a Debug x86 Build configuration it will be $(SolutionDir)bin\x86\Debug and on a Release x64 Configuration build it will be $(SolutionDir)bin\x64\Release.
I googled it and searched it here on Stackoverflow but I can't find a solution.
The closest thing I found is to use Build Events in C# projects and set output to $(SolutionDir)bin\$(Platform)\$(Configuration)\.
But the problem with this approach is that in C# projects the Platform is always set to Any CPU:
And appropriate target platform is set in another field called Target platform:
I've got ProjectA. It has a WinForm and some .resx files in it. I created a Shared Project (ProjectA-shared) and moved everything to it. ProjectA references ProjectA-shared.
When I compile the Solution with VS2013 and the Shared Project plug-in, I get the following exception when running the app:
Could not find any resources appropriate for the specified culture or
the neutral culture. Make sure "Foo.Controls.MyForm.resources" was
correctly embedded or linked into assembly "Foo" at compile time, or
that all the satellite assemblies required are loadable and fully
signed.
When I compile the Solution with VS2015, everything is OK.
I am now left wondering:
Why would there be a difference between the VS2013 and VS2015 outputs?
It looks like .resx and WinForms aren't a natural fit for 'Shared Projects': what is the best way to share this kind of thing between two projects (primarily, projects using Shared Project just so that they can target .NET 4 and 4.5)
I created a blank Windows 10 Universal application with Visual Studio 2015 RC:
File > New > Project ... > Windows Universal > Blank App (Windows Universal)
I want to use existing native libraries provided by a third-party. Those libraries are built from a C codebase and only use whitelisted Windows Store APIs.
I copied foo.dll beside App1.vcxproj then added it to the project and modified link settings to use foo.lib (the import library corresponding to foo.dll) for the x86 architecture. I also right-clicked foo.dll and set the Content property to Yes which makes Visual Studio embed the .dll with the application.
So far so good, I can use / debug my app that makes use of the third-party library. Visual Studio somehow deploys foo.dll next to App1.exe inside the AppX folder. And foo.lib (the import library for foo.dll) manages to load foo.dll successfully when the application start (this is because foo.dll is deployed next to App1.exe).
Now, for that third-party library, I have one .dll file per architecture:
foo/bin/x86/foo.dll
foo/bin/x86/foo.lib
foo/bin/x64/foo.dll
foo/bin/x64/foo.lib
foo/bin/arm/foo.dll
foo/bin/arm/foo.lib
And here comes my question: while keeping a single Visual Studio project for my app, how can I convince Visual Studio to:
deploy foo/bin/x86/foo.dll next to App1.exe when building for x86
deploy foo/bin/x64/foo.dll next to App1.exe when building for x64
deploy foo/bin/arm/foo.dll next to App1.exe when building for arm
What I tried so far is putting the different foo.dll files inside solution folders, e.g.
third-party/foo/x86/foo.dll
third-party/foo/x64/foo.dll
third-party/foo/arm/foo.dll
That could have worked since I can conditionally set the Content property to Yes for each .dll file. However, using solution folders makes Visual Studio deploy the .dll file in a sub-folder, e.g. AppX\third-party\foo\x86\foo.dll for the x86 architecture. Consequently when the application starts it doesn't find the shared library anymore. I wish there was a way to control deployment target location, I think that would solve my use case.
Hope my explanations are clear enough.
Just use a pre-build command line — per configuration so you can copy the right DLL from different source folders to project folder before packaging.
I have a Visual Studio 2008 solution with two projects in it. A C++ DLL and a Csharp application.
The Csharp application uses [DllImport] to access the functions in the DLL, and has a dependency set on the DLL.
For some reason, setting the dependency isn't sufficient to cause VS to copy the DLL to the build path of the app. So the app project has a post-build event which causes the DLL to get copied. (If anyone knows of a cleaner way of doing this, please let me know!)
The problem I have is that when I make a change to the DLL code, then attempt to run the Csharp application in the debugger, VS2008 fails to realise that the DLL must be rebuilt (and re-copied).
I have to force a re-build of the Csharp application (ie by explicitly choosing build, or by "touching" a .CS file).
Does anyone know how to tell Visual Studio to do the right thing?
Edits:
I am using project dependencies. They aren't working correctly.
I am using a post-build event to copy the DLL across.
The issue is that, if you simply choose to debug the application, Visual Studio fails to recompile the changed C++ project, despite the fact that there is a dependency in place.
I know the dependency is working, because if I choose "Build" (as opposed to "Debug") the C++ DLL is built.
"Build" and "Debug" do different things. In Tools - Options - Projects and Solutions - Build and Run, there is a checkbox "Only build startup projects and dependencies on Run". This is checked by default. So, if VS isn't recognising the DLL as a dependency, it won't build it when you choose "Debug".
I don't have VS to hand (only Express), but you could try adding the C++ DLL as a reference rather than a dependency.
Hmm... so I haven't done this exact thing before but I just threw together a C++ lib project and a C# winform project in the same solution. I right-clicked the solution, chose Properties and then under Common Properties->Project Dependencies, I made the C# one depend on the C++ one.
When I make a mod to the C++ one, it will ask me if I want to rebuild the C++ one. There's a "Don't ask me" checkbox too.
Maybe my test is different than your situation, but it seemed to work when I did that.
Hope that is some help.
Assuming the DLL project isn't used in another solution, why not put the post-build event on the DLL app project, so it is always copied?
I've not tried, but can't you do this with the build order?
I have experienced this same issue with applications that have DLL project dependencies. It seems to me that the problem is that Visual Studio only launches the post-build event if it has to recompile something in the Application's project. So, if you modify the DLL source without modifying any of the headers that the Application includes, then the Application is not recompiled because from it's perspective the DLL is the same. Since the application is not recompiled, the post-build event is not triggered. So, the Application is left with out of date DLLs. I have yet to come up with a good solution to this problem.