I am working on a C# application with plugins feature, and found these two MSBuild properties:
EnableDynamicLoading and CopyLocalLockFileAssemblies
They both seem can copy dependency DLLs to the output folder and I tried both of them worked... so what's the difference?
Related
I have a solution with two projects:
C# console application (.NET Core 3.1)
and C++ Dynamic Library (.dll)
I need to call the C++ DLL from the C# project, using DllImport. When I provide the full path of the DLL, the application finds it. But I want to replace the path with a relative path, and I can't figure out how to do it.
First of all, make the C++ project a dependency of the C# project. This ensures that the C++ project will be built before the C# project if it's outdated. You can set the project dependencies in the solution settings.
Now that we ensured that the dll is always up to date, we have to somehow get it in the same directoy as the C# executable. We have two options:
a post build command to copy the dll to the output directory of the C# project, or
we set the output directory of both projects to the same directory.
Post build event
We can simply use a copy command. Go to C++ project settings > Build Events > Post-Build Event and copy the following command to to the Command Line field:
xcopy /y "$(OutDir)*.dll" "$(SolutionDir)MY_CSHARP_PROJECT_NAME\bin\$(Platform)\$(Configuration)"
Replace MY_CSHARP_PROJECT_NAME with the name of your C# project. I'm using the default paths here, depending on your solution you might have to tweak the paths a bit.
Shared build directory
I wouldn't recommend this one, because you can run into trouble with it.
Go to the Build tab in the project settings of your C# project.
At the top of the page select Debug as configuration.
At the bottom of the page change Output path to match the C++ output directory for Debug builds (this one is usually in the same folder as the solution file).
Repeat 2 and 3 but this time with Release instead of Debug.
I'm trying to get my PCL library that uses Nuget packages to copy the dlls it requires to its output directory. For example, I use the Portable Licensing nuget, but it unfortunately does not copy its dlls to the output folder despite having tried multiple solutions/recommendations found on the web.
I've tried a few things based on this page: https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files
Manually setting IncludeAssets to all for each nuget required, locking the dependencies, using the Target build arguments found in another post, etc. Nothing seems to work.
A couple things to note:
I cannot set anything in terms of the nuget refrence. Pic of what my properties window looks like: https://i.imgur.com/cvTQFM6.png
My project does not have a packages.json file. I created a blank project, added the nugets I needed, and copy-pasted the packages.json file from there to my main project, but it still didn't work. The blank project, when compiled, does have the dlls copied to its output directory.
This is a PCL project.
Can I use Nugets properly with PCL projects? Is there some setting I'm overlooking? Any help would be greatly appreciated!
I'm trying to use a Intel RealSense camera in a c# project.
While the example code seams to run just fine.
My own project in a different folder raises an exception.
Unable to load DLL
"realsense2:The specified module could not be found. (Exception from HRESULT:0x8007007E)."
I've now placed the realsense2.dll in lib folder and in debug folder.
I think its a unmanaged dll and the other "Intel.RealSense.dll" seams a .net interface dll . I placed both in lib and in debug folders I tried referencing the Intel.realsense.dll (.net api wrapper) in both locations (debug folder and in lib folder), but to no success.
From Intel forums I noted that sometimes the error gets raised when the CPU model isn't correct, but I kept those the same as the sample.
This must be some visual studio error (since the Intel example works).
But I miss where it goes wrong.
Step 1. Build the provided C++/C# samples using the instructions located in the main repo under /wrappers/csharp/readme.md
Generate the VS solution using cmake (run from librealsense root dir):
mkdir build
cd build
cmake .. -DBUILD_CSHARP_BINDINGS=ON -DBUILD_SHARED_LIBS=ON
The file realsense2.sln should be created in build folder, open the file with Visual Studio, C# examples and library will be available in the solution under Wrappers/csharp.
Both the native library and the .NET wrapper are built by default as part of the examples dependencies.
Step 2. Take a look at the working samples for reference. The default librealsense build on Windows is Debug/Win32 (For this config, built samples will be available at your_librealsense_dir/build/Debug)
In your C# project you need to have Intel.RealSense.dll added as a reference and copy realsense2.dll in your build directory ex: your_project_home/bin/x86/Debug
Note: Looking below, I think it's likely you have all these DLLs. Possibly you have a path issue. Check your EXE is running from the same folder the DLLs are in.
Here are the dependencies of realsense2.dll (x86) output by DUMPBIN:
These Windows ones:
KERNEL32.dll
USER32.dll
ole32.dll
OLEAUT32.dll
ADVAPI32.dll
SHLWAPI.dll
CFGMGR32.dll
SETUPAPI.dll
MF.dll
MFPlat.DLL
MFReadWrite.dll
WINUSB.DLL
And this VS 2017 one:
VCOMP140.DLL
Dependency Walker will tell you which ones you do or don't have.
Why can't I use MSBuild macros in a C# Project's properties? These all work find in a CPP project.
For example:
Create an empty C# console application
Change the main method to take command line arguments
Right click on the project in solution explorer and click properties
Choose "Debug" on the left side
In Command Line Argument's, enter: "$(SolutionDir)"
Debug your program
Notice that the argument is quite literally $(SolutionDir) rather than what it translates to.
I have the same problem with "Xml documentation file path" and other fields.
Why can't I use MSBuild macros in a C# Project's properties? These all work find in a CPP project.
This is because the way C# and CPP project introduce macros is not the same.
For C# project, it introduced by the .props, .targets files, for example, the Microsoft.CSharp.targets file. In your project file .csproj you will find following Import:
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
For CPP project, it introduced by property sheets, you can get it from View->Other Windows->Property Manager, which is not supported by C# project.
The different:
You can use property sheets to create project configurations that can
be applied to multiple projects since project settings that are
defined in .vsprops files are inheritable, unlike project settings
defined in Project Files (.vcproj files). Therefore, a project
configuration defined in a .vcproj file can inherit project settings
from one or more property sheets (.vsprops files). For more
information, see Property Inheritance.
That the reason why you can use MSBuild macros in a CPP Project's properties but not in C# project.
You can check following document for some more details:
Common macros for build commands and properties
Property Sheets (C++)
Hope this helps.
You can use the Property Manager window in Visual Studio for managing common properties of C++ projects, but there appears to be no equivalent to this for C# projects.
Is there a way to set common settings across multiple projects? Examples of things I'd like to do:
add TEST preprocessor directive for all projects that have a TEST build configuration
change warnings to errors for all C# projects
add a reference to some common assembly for N selected C# projects at once
etc.
A plugin, macro, or extension would all be acceptable.
You can customize the C# project template for Visual Studio, so that every time you create a new project it has all the settings you want.
http://msdn.microsoft.com/en-us/library/6db0hwky.aspx
http://www.a2zdotnet.com/View.aspx?Id=170
The closest equivalent is currently using regex from within VS on an unloaded project or writing something to process the msbuild xml backing the .csproj files.
There is no a real equivalent of Property Manager for C# projects.
However, if the goal is to share common settings across multiple projects, you can create a NuGet package with .props file defining the shared properties and reference it in your C# projects - VS will automatically import it at build time.
.props and .targets inclusion is supported as of NuGet 2.x.
Tip: make sure the .props file name matches the NuGet package id, otherwise it won't be included.
You can see an example here.