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
Related
I create a new C# project WPF Application - A project for a .NET Core WPF Application.
Framework: .NET Core 3.1.
Project loaded. (you have an empty form)
Right click on your project and check that you have "Output type" Windows application. (It means when you click on build it creates an EXE file in BIN folder of your project)
Then add a new project to the solution : Setup Wizard by extension Microsoft Visual Studio Installer Projects. Then follow steps as is here -> https://stackoverflow.com/a/6090929/15917420
In the end it packages DLL into installator file instead EXE.
So if you take setup.exe and install it, it installs DLL.
Do you have same problem or am I missing something?
If I create WPF with .NET Framework I dont have this problem.
Thank you
EDIT: recorded video: https://drive.google.com/file/d/11ElC0F62klxQOI-beOn6LhcZbyOb7QDT/view?usp=sharing
I had the same issue. Microsoft has published this:
https://learn.microsoft.com/en-us/visualstudio/deployment/installer-projects-net-core?view=vs-2019
Basically is says that for .NET Core projects, you have to use the "published items" instead of "primary output" when building the setup project. It also has a couple of other hints too.
When targetting .NET Core, the "main" project (the one that is the application) gets two files, a dll and an exe file. The exe file is only a stub loader that locates the dotnet runtime and transfers control to the corresponding dll. Simply put, the exe of a .NET core project is executing the dotnet <dll-with-the-same-name>-command.
With this in mind, you need to make sure that your installer installs both the dll and the exe (and any other similarly named files, such as <Application>.deps.json).
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.
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.
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.
In my web and worker roles, I am referencing an alternative version of a core framework DLL. The file is marked Copy Local. Visual Studio shows the correct version in as a project reference. When compiling the project, the bin directory also contains the correct version.
However, when I ask Visual Studio to create an Azure package, the package (and the csx folder created during packaging) contains the wrong (original) DLL for the Worker role only. The Web role has the correct DLL. This does not occur if I manually use cspack, but that's not really a desirable way to package.
What could cause Visual Studio to compile with the correct reference DLL but bundle the wrong one?
Additional info:
When I run msbuild to do the packaging instead of Visual Studio, I see the following two lines:
Copying file from "C:\Users\bytenik\Dropbox\Treadmarks\lib\EntityFramework\System.Data.Entity.dll" to "C:\Users\bytenik\Dropbox\Treadmarks\src\Azure\obj\Debug\Worker\System.Data.Entity.dll".
Copying file from "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Data.Entity.dll" to "C:\Users\bytenik\Dropbox\Treadmarks\src\Azure\obj\Debug\Worker\System.Data.Entity.dll".
So, it seems to copy my reference, and then copy over it with the system reference.
Note: I'm well aware that the entire concept of replacing a .NET CLR DLL is a huge hack. When .NET 4.5 comes out supporting the feature I need, this will all be stripped out. In the meantime, I need to be able to continue development.
This is a replacement to question "Azure References Incorrect DLL", which was actually factually incorrect and lead to answers that were valid, but did not solve my problem.
Even if a Visual Studio project has a reference to a local and/or modified copy of a assembly that is in the GAC, it will be used during the compilation, but at runtime, the CLR will always load the assembly from the GAC, even if it is sitting right there in the same directory as your application.
So the solution does not involve figuring out a clever way to pack or deploy the modified assembly, but figuring out a way of making the CLR actually load it if it's there.
Two possible solutions:
1) Use a role startup task and an installation project to deploy the modified version of the assembly in the production server's GAC.
2) Remove the signature of the assembly and make sure all references are made to this version without the signature. Beware other assemblies that may be referencing the original signed version and will try to load it from the GAC.
For more details and links see How to prevent a .NET application to use an assembly from the GAC?