Is there any way in Visual Studio or something else that allows the programmer to export the main executable with the dynamic libraries without the need to copy manually some important .dll's from system32 or somewhere else?
For example, OpenGL programs need (beside glut32.dll and opengl32.dll) msvcr100.dll to run.
Is there any efficient or professional way of deploying applications that use dynamic libraries?
There are two ways to do this in Visual Studio Setup and Deployment project:
Project - Properties - Prerequisites.
Project - Add - Merge Module.
The second way is more flexible and may be used for third-party merge modules, not included in Prerequisites dialog.
Of course, if you don't have Setup and Deployment project yet, create one for your application.
Related
I'm a bit of a noob on that topic so I'm searching for help. I need to install this library (https://github.com/twcclegg/libphonenumber-csharp) for a unity project where I need to check phone numbers.
But as I always made simple games in unity I really don't know how to do that and I don't really know either what to search to find an answer.
If anyone of you knows how to do it, it will really make my day.
Thank you
Once do a build on a project you want to use in Unity, then find the DLL output from the build. I recommend you do Release Builds, but for now if you are not familiar with Visual Studio just use what you were able to build. If there are multiple directories then you only need one - the best one to use would be any labelled ".NET Standard" which it seems you have a .net standard 2.0 directory.
Go to your Unity project in the Assets folder, and if there isn't already a Plugins folder create one. Then in Assets/Plugins create a folder named whatever you want for the library - in this case PhoneNumber would be fine. So you would have Assets/Plugins/PhoneNumber and you would copy/paste the contents of your NetStandard2 folder there.
In the end you should have Assets/Plugins/PhoneNumber/PhoneNumber.dll
As soon as you have that dll, you can switch back to Unity and see if it worked by checking the Unity Console for any Errors. You might receive errors saying it could not load the DLL. Almost always if it can not load the DLL it is because of missing dependent DLLs - which is why I said to copy the entire folder contents inside the "NetStandard2" folder since it may contain more than just PhoneNumber.dll - it may have it's necessary dependent dlls also.
If not, you can read the error output and hopefully get a clue as to what dependent dlls are missing. You can also expand the Dependencies in Visual Studio.
Typically the DLL failing to be loaded in Unity is because of missing dependent DLLs. Expanding the Dependencies, which is found under the project name in the Solution Explorer window on the right side of Visual Studio, will show you what libraries it requires. Most of what you see under dependencies (if not all) will require a similarly named dll. Under the netstandard2.0 dependency I see System.Collections.Immutable - so you may need a System.Collections.Immutable.dll which should (usually) be in the output folder when you build the project. You would also need that dll in Unity in your PhoneNumber folder along with PhoneNumber.dll
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.
Just maybe trivial, maybe stupid question.
I have two solutions:
1) The main app
2) The sets of libraries
The first solution is accessible via the SourceSafe with the dll files(from the 2 solution) placed in its lib directory.
In order to debug the main app with the ability to jump to the source code of the libraries from the 2 solution Do i have to add the projects from 2 to 1? And Is it the only one option?
Even if I added (if it is possible to add with omitting certain projects in the SC) projects from 2 to 1 solution, I would have to change dll references in the app which is controlled via SourceSafe and I would mess it up for my colleagues.
What Can I do?
To debug all you need is that all third-party dlls have their corresponding pdb in the same directory. When you step into a third-party function for which you have pdb, Visual Studio will prompt you for the source, At this time you may browse to a local or network share where you have a the third-party source.
The place I used to work for used .NET Reflector to step through external DLLs. It's a Visual Studio add-on that uses reflection to allow you to debug through the source code of .NET binaries (actually their MSIL reversed equivalents) and is pretty simple and efficient when it comes to non-obfuscated code.
I need some help regarding Visual Studio solution and project organization.
I have a solution with several projects. All of them are written in C# and are compiled as libraries to be used by the GUI. Some of these libraries have also dependencies with others. For example, TestExecutive needs LoggingFramework, Communications needs LoggingFramework too.
Which is the best way of organizing? I'm thinking on a folder assemblies to hold libraries' binaries in one place. Something like:
Solution
|
|-- TestExecutive
|-- LoggingFramework
|-- assemblies
There is also another problem. One of the projects uses a native C dll. Where do I have to place this library? With the librarie's assembly or with the final executable?
EDIT:
Ok, now suppose I have the WinForms program running. I have source code and binaries mixed. Which features do I need to generate something I can distribute? I mean, with all the libraries and configuration files, but without source code. I have done this before with Nullsoft installer, but I don't know if visual studio can help you doing that.
A few things here:
When one project depends on another, you can set up that dependency in Visual Studio. Right click on a project and select Project Dependencies...
For other .NET assemblies that are NOT part of your solution (3rd party tools, etc.) I do exactly what you showed here -- I have a separate folder parallel to the projects. Then I set up the assembly reference in each of the projects with "Copy Local" set to true and it works fine.
For native C dlls, it's a little different. There is no direct reference to them in the references section of the solution explorer. The compiler isn't going to look at the dll to check your p/invoke references or anything like that. You just need to make sure the dll is part of the deployment on your top level web or winforms project. It's a content file just like a css file or image or something. Just add it as a file in the project and make sure the "Build Action" is set to Content so Visual studio knows to just copy the file as part of the deployment
I set my solution folders up a bit differently than you. At the top level I have the following folders:
\build
\lib
\src
The build folder has build scripts (NAnt, MSBuild, etc). Any 3rd party assemblies (or anything I'm not building in the solution) get put into the lib folder, in an appropriate sub-folder. For example, I'll have log4net, NUnit, RhinoMocks folders in the lib folder, each containing the files needed for that dependency. The src folder has the solution and all project files.
I like this structure because it clearly delineates between the project code and the other stuff that is required by the project. Also, I usually set up some custom build tasks to copy the resulting assemblies for my project into either a \deploy or \lib\ folder. This way you don't have to hunt in the \src\\bin\\ folder to get a built assembly or the whole project; however this seems a bit beyond the scope of your question.
Btw... I didn't come up with this structure on my own, I think I started off using Tree Surgeon and evolved my process from there.
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.