I have used .Net Reactor to obfuscate code. Now how do I create create setup package for the obfuscated code. Or are there any other tool for creating setup package for obfuscated code.
Thanks in advance.
Not sure why this is a problem. Why don't you create the setup package before obfuscating the assemblies?
I had no problem with BitHelmet Obfuscator. My setup package just uses the obfuscated assemblies in BitHelmet's output folder, instead of project output.
Works fine.
Are you using the VS included setup project? For that, the obfuscator needs to support MSBuild based obfuscation, so that the obfuscation takes place as part of build process. This way, the obfuscated dlls are available for the setup project.
I found a way to do with Dotfuscator. Below are the steps.
You need to create Dotfuscator project first, i.e right click on solution->add project->select Dotfuscator as project type. To the project created right click on Input-> map to project output from your actual project. Build the Dotfuscator project. Next add the setup project. Point setup project output to that of Dotfuscator. And now build to create the setup. Now your code is obfuscated.
Now I am looking for a solution to work with .Net Reactor, obfuscation and add the output to setup package.
You can use the .NET Reactor VS Add-in in to automatically obfuscate the assemblies. This way your setup package will include the obfuscated files.
The solution is described here: Solution
Related
So I have a C# application that I am developing in Visual Studio. I am using a NuGet which was really easy to install. Newtonsoft JSON. I just had a quick question because I am new to windows development.
I know to use somethings in your project you need to add the dll or lib to your installer as well, in order for the project to use that library. Is this the same case for a NuGet? Do I need to add Newtonsoft JSON to my installer?
Im using Visual Studio 2015 if that matters.
Was going to just comment but can't yet.
In general, adding a package to a project through Nuget takes care of all the necessary referencing.
Also, if you look in your reference list in the project, and right-click on the assembly in question (in this case Newtonsoft.JSON), and go to its Properties, you will see an option "Copy Local".
If this is set to true, as the description says, "the reference will be copied to the output directory".
So, wherever your .exe/.dll/lib is output, there should also be a copy of Newtonsoft.JSON in there as well.
Edit:
As your question is quite confusing, the best I can say is that if you add a package through Nuget, it will NOT be built into your application, it will still be a separate DLL file that DOES need to be included in your installers list of included files.
You don't need to install nuget package to you installshield project.
You need need to include reference in you install project to your dependency.
It will depend on the installer you use. Some will let you select the folder and will detect it automaticly, some don't.
I have a requirement to package up and release a .NET control library across multiple platforms and have a question on how to automate this deployment (or make as efficient as possible) through build scripts and VS2010 configurations.
The control library is to be released as a Silverlight version (separate builds for SL 3.0, 4.0, 5.0) and WPF version (separate builds for .NET3.5 / .NET4.0). I also need to specify release and trial versions of the same libraries. Trial versions will be differentiated in code with a preprocessor statement TRIAL. Both the trial and full version will be compiled in RELEASE mode.
I'm wondering how to achieve this in the most efficient way possible. My VS2010 solution currently has one project for WPF (.NET 4.0) and one separate project for SL (SL 4.0).
Do I need to create further csproj projects for the missing versions, e.g. .NET 3.5 and SL 3.0 and 5.0?
I wish to create one MSI for all Silverlight DLLs and one MSI for all WPF dlls. Do I need to create further MSIs for the versions compiled as Trial? What about separate MSIs for each version of the .NET or Silverlight framework?
Is it possible to achieve the above deployment packaging using build.targets or build scripts?
Basically if I create manually MSIs for all the above combinations and do a full rebuild that would work, but it is also a laborious process when releasing updates. I am looking for suggestions on how to achieve this with build scripts, build.targets, MSI configurations or a combination of the above.
Finally when redistributing the control libraries, installation should ideally result in registration in the GAC.
Any comments / suggestions welcome.
Best regards,
If you are releasing for different versions of the framework, then you will need different projects. You probably could get away with switching the target framework at runtime, but there are so many variables, by the time you get them all figured out and tested, you could have easily created the additional projects.
I think it would be well worth your money to invest in an Installation tool such as Installshield that has built-in support for the rest of the functionality that you desire.
I believe that you should be able to accomplish all of your needs in a single installshield project using various switches and end user keys (to trigger trial or real installs), but you may potentially consider separating trial and real depending on your licensing scheme.
Update
You can also solve this issue through a pure VS2010 solution, it's just more complicated.
Based on your goals, you will need to have a total of 5 projects and each solution will have 2 configurations, one for release one for trial (where the preprocessor define is set).
You might be able to get away with a single build solution that contains all 5 projects since you can reference the output from each project separately within the VS setup project.
On release, you will have to run the build twice, once for release and once for trial, but you can easily automate this with MSBuild.
What we did to ease the release process burden was create a small database to hold configuration information about the products (locations of solutions, project files, and assemblies) and a small UI application that builds the apps by first changing the version everywhere necessary and then building the installer solution through the visual studio build process.
One very important note that I just remembered as I was typing the above: at one point (it may have been fixed), it was not possible to build Visual Studio 2010 setup projects through MSBuild, which is why we went with building through devenv.com.
For posterities sake I'm recording the solution I came up with thanks to competent_tech's very informative answer.
Solved using an msdos batch file as follows.
Dumped the idea of #If Trial switch. Instead component is licensed by licx file so trial build is the same as release build. This means just one solution for dev work which build outputs are derived from
Created a batch file to rebuild Silverlight and WPF output projects with MSBuild, switching toolsversion to create multiple versions
Copied DLLs over to Nuget style directory structure, e.g. Build/lib/net40, Build/lib/sl4, Build/lib/sl5 etc...
Obfuscate built libs in place
XCopy example projects over to Build/examples/
Use Powershell to edit example projects to reference new obfuscated output.
For reference, please see the following questions and answers on removing/re-adding references and editing project files with powershell
I have a question regarding c# open-source projects and dependencies. For example, I am currently working on a few projects. One is a C# project that produces a class library with specific functionality. This project should be hosted as other projects will find this functionality useful.
The next project I'm working on requires a reference to the class library project which is under separate version control.
So how can I structure an open-source c# project with a dependency to the class library project without including the source code of the class library project?
Any example projects to study would be great too! :) Thanks in advance!
If the open source depency is on listed on Nuget then the easiest way is to add the Nuget package, and make sure your packages folder and packages config file is included in the project.
Unless you want the actual source, then this is the easiest way to add binary dependencies. It includes the PDBs so you get the lines of the original source code.
Include a cmake script to gather dependencies in the application source code. The cmake script will check for dependencies, and any that are missing will be downloaded.
You could experiment with the cmake script being a pre-build step in the solution; But for now dependencies are updated manually.
The script is the same no matter which system it is on, which is the beauty of cmake's script mode.
Although this is a bit clunky, it seems about the best way to include a source-code version of an external dependency which is not a part of the applications version control.
as an example, you can get a launchpad project:
bzr branch lp:~brian-sidebotham/+junk/valverschatcam
from the root of this project, simply run:
cmake -P build.cmake
Obviously the script should probably be called deps.cmake or similar instead of build right now.
Project1: A C++ EXE project with code
generation option "runtime library" set to
"Multithreaded Debug Dll".
Project2: A C# EXE project developed
with .Net Version, say, 3.5
Suppose I want to write an installer project for these projects. I naturally include their primary outputs (the exe's) in the installation package. But the exe's are not sufficient to ensure that they will be runnable on the target machine. In case of project1 we will need msvcrt.dll and possibly others(not sure), and, in case of project2 we will need the .NET framework of the corresponding version. The question is, is it possible to make the installation package automatically include those? If it is not, how is it best done manually? TIA.
It is already automatic afaik. Every time I tinkered with a Setup project, it already figured out the prerequisites from the projects I added. From your Setup project, use Project + Properties and click Prerequisites. Verify that the right Visual C++ Runtime Libraries and .NET Framework are ticked.
I have a console application and two class library projects.
The console application has to project references to the class library projects.
When I build, it generates DLLs for these two projects. Do I have to include these with my console applications exe file? Is there a way I can make it so I don't have to include these 2 dlls?
Ideally, I'd like to have a single exe.
You must include any referenced assemblies as they are dependencies of your application.
That being said, however, Microsoft offers a tool called ILMerge that will allow you combine the dependency assemblies with your executable to create one, all-inclusive, executable assembly that you can ship to customers.
Check out ILMerge.
You can merge the assemblies into one, using ilmerge, otherwise you'll have to deploy the exe file and the dlls.
e.g. you can run a command like
ilmerge /target:winexe /out:MyProg.exe Program.exe ClassLib1.dll ClassLib.dll
Visual Studio provides no built-in way to do this, so you'd have to run the above command manually,as a Post Build event, or add it manually to your .csproj file.
You should be able to accomplish by selecting your references and setting the "Copy Local" property to false.
Be careful with ILMerge and make sure you understand the performance implications of going this route.