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.
Related
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.
Small question : If a dll is being referenced from C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.6.1, how does an application link/finds that during runtime? (or when launched without VS)?
Is it from GAC or the dll is copied into executable location at runtime?
The Framework you build with (4.6.1) has to be installed on the client (GAC) to run. Standard with normal Windows client/server.
If you want to embed the DLL in your EXE, have a look at Embedding DLLs in a compiled executable.
I highly recommend to use Costura.Fody - by far the best and easiest
way to embed resources in your assembly. It's available as NuGet
package.
Install-Package Costura.Fody
After adding it to the project, it will automatically embed all
references that are copied to the output directory into your main
assembly. You might want to clean the embedded files by adding a
target to your project:
Install-CleanReferencesTarget
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.
I am using .Net Reactor To Obfuscate my project.
In my project I have about 10 dlls.
I want my setup to deploy the obfuscated dlls in client's machine.
I tried putting the code below in Post-Build Event at Properties of the setup Porject.
"C:\Program Files\Eziriz\.NET Reactor\dotNET_Reactor.exe" -project "E:/s.nrproj"
But when i deploy it and try to open the deployed dlls in Reflector, it Opens and show the code.
Where/What am i missing???
Dot Net Reactor obfuscates exe's and dll's and stores them in a different location. Default is the sub folder Secured where the assemblies were. Be sure to take the secured ones and not the original ones in your deployment scheme !
You should obfuscate your assemblies before building your setup project, therefore you should use your command in Pre-Build instead of Post-Build. When you obfuscate your assemblies it is possible that .NET cannot recognize your required assemblies automatically. I strongly recommend that obfuscate your assemblies separately and then create your setup project (ensure that all of required assemblies are added to your project).
NOTE: There is some bugs about creating setup project in VS2010, sometimes closing and opening the visual studio works.
This works on my side:
if /I "$(ConfigurationName)" == "Release" "C:\Program Files (x86)\Eziriz\.NET Reactor\dotNET_Reactor.Console.exe" -file "$(TargetPath)" -targetfile "$(TargetPath)" -q
and if you want to set config proj then add it like this:
-project "$(SolutionDir)obfuscation_settings.nrproj"
Given that .net reactor project is placed in solution folder and its name obfuscation_settings.nrproj
Good luck
The Post-build event doesn't work in this case. You can use the .NET Reactor VS Add-in in order to obfuscate the assemblies at the right time. The solution is described here:
Solution
I am referencing a VB6 dll in my dot net project.
to do this I need to register the dll using regsvr32 tool.
when i build my project the Interop dll is getting created in obj folder and not bin folder.
Do I need to add the VB6 dll to wix project and register it. If yes how do I achieve it.
I tried adding it to wix project but as its not created in bin folder i am getting error.
Could anyone please help me on this.
Thanks
You install the vb6 Dll the same as any other file, with the addition that the Heat tool is used to harvest the registration entries from it. You don't need regsvr32.
If you want your interop dll in a specific location at build time, I suggest you explicitly use the tlbimp.exe tool to create the interop dll in the required build location so the WiX build can find it.