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.
Related
I have a fairly large project in Visual Studio 2010
I can build the project in both Debug and Release mode, copy the generated exe file along with a custom dll I need for a function in the program to another computer, and the exe file works without any problems
I am trying to make an installer for this project in Visual Studio 2010, following the instructions here: https://www.technical-recipes.com/2011/how-to-create-an-installer-in-microsoft-visual-studio/
I do not get any errors while building the installer, and I get a setup.exe and an msi file as a result, but if I install my program in another computer (not by development machine), when I try to run my program after installation I get a missing api-ms-win-crt-runtime-l1-1-0.dll error
How do I debug this problem? Since I can simply copy my Release or Debug build to the computer and make it work, doesn't it mean all the dll files my program is dependent on already exists in the other computer? And if this already works, why isn't the installer version working? How do I make sure that everything I need for this program is included in the installer?
My project in MFC dialog based and uses one third party library, for which I have both .lib and .dll file available. I need to do this in Visual Studio 2010. My development machine is Windows 10 64 bit Home edition version 1909. The installer I currently create installs my program in Program Files (x86) folder.
Static Linking MFC: It appears this issue was solved by making sure to statically link to MFC libraries. In the VC++ project: enable the setting: "include MFC in a static library". This enables static linking of MFC components, eliminating the dependency on shared dlls.
This is a common "missing runtime error" - there are generic check lists below which include this as one source for application launch problems.
Warning: Generally static linking should be avoided in order to benefit from security updates to shared dll files via other update mechanisms.
Short Version: In Visual Studio Installer Projects, check if the Visual C++ Runtime is available in the Prerequisites list.
See this answer, here is a quick screen shot:
Tools: If your project is large you might want to consider another MSI tool. There are many limitations with Visual Studio Installer Projects.
Merge Modules: There are merge modules to install the Visual Studio C++ Runtime, but it is recommended to use the setup.exe for these reasons.
Visual C/C++ Runtime: You are probably just missing the Visual Studio C/C++ Runtime. It needs to be deployed with your application, it is not on there by default (unless you link statically, in which case it should not be needed). Skim this list quickly for other ideas.
You can download the VC++ redistributables at ("The latest supported Visual C++ downloads"):
https://support.microsoft.com/en-us/kb/2977003
More Information:
More on the Visual C/C++ Runtime
Secondary Links:
Detecting presence of Visual C/C++ runtime on box
Missing Dependencies and check lists
Scan for application dependencies
Installing VC++ Runtime with merge modules
I'm going to create my first managed plugin for Unity (2018.2) using Visual Studio Community for Mac (7.6.11 build 9).
I've read the documentation but I think that the step-by-step instructions are not meant to be followed on Visual Studio Community for Mac.
As you can see in the screenshot below, I've created several projects using each and every library template available.
All of them compiled successfully to a DLL targeting versions of .NET framework that are incompatible with Unity.
The only project I could change the .NET framework version to match Unity's 3.5 is the one based on the Other > .NET > Library.
Everything works fine but I'd like to know if the assumptions, the process and the final result are correct. Can you tell me, please?
I don't know the difference between the "Class" and the "Class Library" option but you're supposed to use the "Class Library" option. This is not the main point of this answer.
Two future issues you haven't solved yet:
1. Referencing Unity's API.
If you ever have to use any Unity library or API in youir plugin such as Vector3, you need to add Unity's UnityEngine.dll to your library settings. If you don't, you will run-time exceptions.
Go to Project --> Add Reference ---> Browse ---> Browse Button
then select <UnityInstallationDirecory>\Editor\Data\Managed\UnityEngine.dll. You can now build your managed plugin. Since you're using Mac, this path is different on your OS. On Mac, this could be /Applications/Unity/Unity.app/Contents/Frameworks/Managed/UnityEngine.dll. You just have to find where UnityEngine.dll is located.
2. Invisible stack trace
With your current setup, if you run into error with your managed plugin, the stack trace won't be there. You won't have the file names and line numbers and this makes is very hard to debug your plugin code.
When you build the project, Visual Studio generates a PDB file instead of an MDB file. Unity can't use this directly. You have to convert the PDB files into MDB files.
From command line, run this:
<UnityInstallationDirecory>\Data\MonoBleedingEdge\lib\mono\4.5\pdb2mdb.exe UnmanagedPlugin.dll
Again, the path might be different on Mac, you just need to find "pdb2mdb.exe" that converts the PDB files into MDB files.
After that, copy the MDB and dll file into the "Assets" folder in your Unity project.
I have a VisualStudio (2015 in case it matters) solution which has a C++ project compiled as a DLL, and that DLL is then used via DllImport in a C# Windows Forms project that is my executable. Let's call this executable ExeA. Because this ExeA needs my DLL in the same directory as the build location for ExeA.exe, and because I build for multiple platforms, in both Debug and Release flavors, configured the C++ project settings to have
<OutDir>$(SolutionDir)ExeA\bin\$(Platform)\$(Configuration)\</OutDir>
This makes sure that whichever way I build my executable project, the DLL is always delivered to the correct folder. However, this hard-codes ExeA name into the C++ project settings.
I am now adding a secondary C# executable project, let's call it ExeB, which must also use this DLL. Ideally, I would modify my C++ project settings to pick up the name of the target executable project from some Visual Studio variable. I looked here, but could not find a variable that represents the name of the project within a solution which is currently set as the "executable" project. Does anyone have any suggestions?
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.
I have a VS 2010 solution that contains a website that has a web service within it. The web service references a COM dll that is causing problems when the solution is built on our 64-bit build server. I get the typical 32/64-bit error:
ASPNETCOMPILER : error ASPCONFIG: Could not load file or assembly 'xxx' or one of its dependencies. An attempt was made to load a program with an incorrect format
When I build the site using the 32-bit aspnet_compiler it builds okay. So, how do I specify that a website should be built as 32-bit? The Configuration Manager within VS will only let me choose Any CPU, so I cannot change it to x86 for this website...
Thanks.
You can use the following command. Actually, in this case you are using ASPNetCompiler x86 edition to build your own project
call "C:\Program Files\Microsoft Visual Studio 2008\VC\vcvarsall.bat" x86
MSBuild MySolutiuon.sln
You can also use x86_amd64 for any cpu. Note that instead of using MSBuild you can load your confiiguration like
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="PrecompileWeb">
<AspNetCompiler
VirtualPath="/MyWebSite"
PhysicalPath="c:\inetpub\wwwroot\MyWebSite\"
TargetPath="c:\precompiledweb\MyWebSite\"
Force="true"
Debug="true"
FixedNames="True"
/>
</Target>
</Project>
to use above confiuguration you have to use
MSBuild your.xml /p:Configuration=Release
#Vilx, Check the dependency walker to find out how far it gets. My guess is it would probably stop at vjsnativ.dll. If that's as far as it gets, try this workaround.
Otherwise you'll have to chase down each DLL that the program can't find, and copy them into your program (or its bin) directory.
Its not the compilation problem but the environment problem. The ASP.NET Website will always be built as Any CPU.
However, if you load it on 64 bit machine, by default 64 bit version of IIS is running which
is unable to load COM DLL and it fails.
You need to configure IIS to run 32 bit applications on 64 bit Windows:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/iis/405f5bb5-87a3-43d2-8138-54b75db73aa1.mspx
You need to use the ASP.NET Compilation Tool (Aspnet_compiler.exe). Look for the ' Finding the Correct Version of Aspnet_compiler.exe' chapter at the end of the doc, it explains how to find the 32 vs 64 bit versions of the tool.
Right-Click on your Web Project in Visual Studio.
Select "Properties".
Click the "Build" tab on the left.
Under "General" change the "Platform Target" to "x86" so it will always build for 32-bit.
Now when you do this you may notice on the same "Build" tab that the "Configuration" is set to "Active (Debug)". You will need to change that drop-down to all the different configuration settings you have (i.e. "Release", "QA", "Staging", "Demo", etc..) and make the same "Platform Target" change to "x86" for each one.
Don't forget to click the "Save" button when you're done - remember to set it back to "Debug" if you're on your development box.
That's probably why it only works when you build it on your machine, and not on the Build Server as the Build Server is most likely set up to build against a different configuration - which is correct, because you shouldn't be using the "Debug" configuration on a Build Server.
Although this is an old question, I was faced with the same problem and I had some troubles finding an answer.
Visual studio offers two options for developing web applications: web sites and web applications. We applications generate assemblies per page, which are dynamically updated if the source changes. On the other hand web application projects are compiled in visual studio to one assembly. This assembly is not automatically rebuilt after changes to the source code. The differences are explained in detail in this document: http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx#wapp_topic5
Another difference, which is relevant here is that web application projects allow you to actually choose an architecture contrary to web site projects. Converting a web site to a web application is not very hard, but not too straightforward (the option convert to web application is only available after creating a ... web application). Steps you can take:
Create a new web empty web application
Browse to the directory of new web application and copy all files from your website (overwriting anything in the directory)
Add all files to the project
Right click the project and choose “Convert to web application”.
It may be needed to solve a few namespace issues.