I am compiling a solution using Visual Studio 2019. This solution has two projects, we can call them Common and Program. Program depends on Common and Common depends on the NuGet packages LibVLCSharp, LibVLCSharp.WPF and VideoLAN.LibVLC.Windows.
If I clean and then build Program, everything is fine: the dlls are correctly copied in bin/Debug or bin/Release. But if I make any change to Program and compile it without cleaning it, the dlls relative to VLC disappear.
What can be the reason for the dlls to disappear?
In the visual studio UI I do not see the commands it is running when I compile the project. How can I debug it?
It seems that you are referencing VideoLAN.LibVLC.Windows on your Common project rather than in your Program project. This is not a scenario that we support.
I wrote this explanation about which project you should install LibVLC in.
In short, you should install the LibVLC package only into your application project, because we insert a build step that copies the files to the Output Folder of your project.
If you reference the LibVLC project in the Common project, there is no way we can copy the files to the Program project, because it is not known by MSBuild. You would then have to tell MSBuild to copy those files from Common/bin/... to Project/bin/..., but trust me, you don't want to mess with MSBuild.
EDIT: That doesn't mean that you can't use LibVLCSharp in your Common project. You can reference the LibVLCSharp packages in your Common project, because it only depends on VideoLAN.LibVLC.Windows at runtime.
Related
I have a DLL with tools i use in several projects. The DLL is frequently updated with new functions. How can i automate the replacement of the DLL in a way so that i dont have to manually copy and paste?
The way i do it now is that i build my project with visual studio, manually copy the DLL file from bin/debug folder and paste them into the root folder of the different projects that use it.
I know gacutil is used to register DLLs to the GAC and that i can make a batch file that does this.
If i install it to the GAC and the projects reference them there, will they be updated? What typicall options are there?
You should look into packaging the library as a NuGet package.
If that doesn't work for you, there's post-build events in Visual Studio that you can use so that the copy & paste is done automatically for you.
Some background:
At my company, I have been working the last few months with converting our C# libraries to function on .dll references instead of project to project references. To do this, we have created a local NuGet server which contains NuGet packages for all of our libraries projects. We have Jenkins jobs set up for every project which build new NuGet packages and add them to the server every time a change is made to one of them.
For working on a single project, this system works great. You only have to worry about updating your packages folder through Visual Studio's NuGet manager, and then the rest is just writing code and building.
The issue:
When you add a new reference, or update your packages through NuGet, NuGet automatically specifies that specific version of the project that you selected in NuGet. With the current system I have setup, rebuilding a project locally will then replace it's .dll in the packages folder so that all projects that reference it can see these new changes you're testing. However, the issue come in that locally built projects have a different version than our Jenkins built packages. Our local builds use a different versioning system from our Jenkins builds so that you can easily tell whether something was built using Jenkins, or if some of the .dlls came from a developer's build. Because of this different versioning scheme, the reference of projects to the project breaks, because the new .dll that was built locally has a different version than the .dll that was retrieved from the NuGet server.
Current Solution:
For the moment, I have resolved this through the addition of a pre-build step. Before every project builds, the project calls one of my PowerShell scripts, which goes through and adds <SpecificVersion>False</SpecificVersion> to every project reference in the project being built's .csproj file. This resolves the issue, but only in the sense of putting a bandaid on it. Instead of dealing with the consequences of the system, I wanted to prevent them ahead of time so that this isn't needed every time a project builds. I have tried researching a lot about NuGet packages specific versioning issues, but have not been able to find anything online even remotely close to what I am asking. This makes me think that I'm going about this wrong.
The question:
What can I do to solve this issue? Or am I doing something very wrong and dumb that could be easily avoided by using another system? Any suggestions or tips would be greatly appreciated
I have a solution with 4 projects:
a C++ .lib "A"
a C++ .dll (based on SWIG generated wrapper) "AWrapper"
a C# .dll (based on SWIG generated wrapper) "ASharp"
a C# Unit Test project (default, yet I can port it to NUnit) "ASharpTests"
Looking at general documentation, C# Travis CI docs and C++ docs cant get how to solve such multylingual project problem.
I can create CMake project for C++ library and wraper. But what shall I do next, how to solve next problems:
How to compile only selected projects from VS solution?
How to mix multiple lenguages, what one shall write into Travis configuration (2 C++ projects, 2 C# projects, to run tests a .so build from C++ code must be at the same folder as C# tests)?
CI Build Tool - MSBuild
If you are using Visual Studio to build your C++/C#/VB/other solutions, you should use MSBuild as the CI build tool.
See: https://msdn.microsoft.com/en-us/library/dd393574.aspx
MSBuild may be used to build project files in Visual Studio (.csproj,.vbproj, vcxproj, and others). However, it is not recommended. Instead, MSBuild should build Visual Studio solutions (.sln) directly. The main reason is that this way the Visual Studio IDE (used by developers) and MSBuild command line (used by CI system) build a solution exactly the same way. Secondly, changing configuration will be in one and only one place when changing projects by using the Configuration Manager in IDE.
MSBuild XML script example:
<Target Name="BUILD_SOLUTION">
<MSBuild Projects="$(SOLUTION_NAME).sln" Properties="Configuration=Release;Platform=Win32"/>
<MSBuild Projects="$(SOLUTION_NAME).sln" Properties="Configuration=Release;Platform=x64"/>
</Target>
Remember to Set Project Dependencies and Check Project Build Order. For examples,
Common libraries built before final EXE projects;
Unit Test projects built after corresponding production projects.
MSBuild Properties="Configuration=x;Platform=y" maps to Configuration Manager. Remember to set all Configuration and Platform combinations:
Select (enable checkbox) Build for each project context if needed;
Deploy column is not used.
I suggest you to set up your Travis configuration as C# (ie. language: csharp). With this, your project will be integrated in a C# environment with all the necessary tools. For your two C++ projects, it should not be too difficult to install mandatory tools. It as simple as a sudo apt-get install g++ cmake (and other required packages). You have to do this in the install section of your .travis file.
Note: The exact manner to install missing packages may vary depending if you use the docker-based Travis infrastructure or the legacy one.
Then, in the script section, you can build your c++ projects with cmake and then build your C# projects.
I know people normally add a dll file into the reference of Visual Studio very easily as follow:
1) Right Click on Reference
2) Choose Add Reference
3) Browse and choose dll file
However, with this approach, VS seems to store the absolute path, pointing to my dll file, rather than copy dll file into VS's project memory.
What if I remove the dll file from the hard driver? or what if I want to deploy the project on another computer?
Sorry, I am quite new to .Net
As described in your question, this is the way you reference a class library or any other DLL-like reference.
Once compiled, your project copies its dependencies into its bin folder where you can find the referenced DLLs.
If you can't find the referenced DLL, set its Copy Local property to true.
Another way around is to set your Reference Paths. This will force, on compile-time, your project to update itself with DLLs from the specified reference paths.
The best practice was to create a Shared folder where all referenced libraries were in, so that you could write your reference paths once and for all per project.
Technologies being so great and vast on improvements, there's now NuGet Package Manager.
What is NuGet?
A collection of tools to automate the process of downloading, installing, upgrading, configuring, and removing packages from a VS Project.
How to use NuGet?
You may install it from within Visual Studio if it is not already installed, through the Extension Manager.
Otherwise, please visit the NuGet CodePlex Home Page.
Here's how Finding and Installing a NuGet Package Using the Package Manager Console has never been easier! =)
So when you open up an existing project, NuGet manages to get all the dependencies for you without any more effort from you. This should solve your concerns.
this might be a bit of a noob question..
I've coded a simple file conversion app in C Sharp (.net 4, VS2010) that uses the Filehelpers library. I've got a reference to the library in my project references. When I publish the project in Release mode, it outputs the Filehelpers.dll file with the executable together, and the executable won't work unless it's in the same folder as the DLL.
I tried setting Copy Local to False, but it still doesn't work. Is there any way to package the library as part of the exe file?? This is a very simple app which is meant to be distributed easily and having this required Dll floating around is a huge downside.
thanks
T
Got it working after some fiddling with ILmerge not running on .net v4. Here is my command for future thread visitors:
ILMerge /targetplatform:v4,C:\windows\microsoft.net\framework\v4.0.30319 /out:merged.exe /log Original.exe FileHelepers.dll
You may want to look in to your project property settings where you can custom copy files where ever you want post build if you are looking to move files around after the build. If you are looking to include a .dll in your .exe look here