MSBUILD Dynamically Create Config XML Dotfuscator - msbuild

I am trying to obfuscate bunch of files in a directory and every build there are more and more files being generated. I would like to know if there is a way I can dynamically create the Dotfuscator configuration xml file using a MSBUILD task that will generate the xml file every time there is a new file added to the directory?

This might be a good time to use the Directory input. Rather than representing a single assembly (.exe or .dll), this type of Dotfuscator input captures all the assemblies in a directory. When the contents of the directory change, Dotfuscator's build will automatically pick up any new assemblies.
To make a Dotfuscator config file with a Directory input, open the GUI and add an input as you normally would (directions for Community Edition's GUI and for Professional Edition's standalone GUI), but instead of selecting a file from the Browse... dialog, just navigate to the directory and click "Open" while the "File name" is still listed as "Folder Select". Then, save your configuration.
From now on, whenever you run Dotfuscator (whether from the standalone GUI, the command line, the Visual Studio integration, or the MSBuild task), all assemblies in the directory will be processed as input.
Note: If you look at the config file itself, you might be surprised that it will still list individual assemblies:
<input>
<loadpaths />
<asmlist>
<package refid="19e1b0c5-7221-476f-af4b-bafef68edc95">
<file dir="C:\code\BasicTestApp\BasicTestApp\bin" name="Debug" />
<asmlist>
<inputassembly refid="a6da5d8d-c181-4103-840d-d8cc7c85937a">
<option>honoroas</option>
<option>stripoa</option>
<option>transformxaml</option>
<file dir="" name="BasicTestApp.exe" />
</inputassembly>
<inputassembly refid="df84dad0-fbe8-49ab-b8c8-9fb59e706785">
<option>honoroas</option>
<option>stripoa</option>
<option>library</option>
<option>transformxaml</option>
<file dir="" name="ClassLibrary.dll" />
</inputassembly>
</asmlist>
</package>
</asmlist>
</input>
Despite this layout, Dotfuscator will process all assemblies in the C:\code\BasicTestApp\BasicTestApp\bin\Debug directory when it runs a build based off this config file, not just those two listed.
The assembly elements in the config are just there so that you can still make rules against individual assemblies in the GUI (e.g., to make one assembly be in Library Mode).
The list represents the state of the directory when the GUI last modified the config.
Disclaimer: I work for the Dotfuscator team, and am answering this question as part of my job.
Additional note due to clarification in the comments: the directory package has a feature where you can exclude certain assemblies from obfuscation. These assemblies will be treated as a Package Artifact and just copied from input-to-output without modification. Any obfuscated assemblies that refer to these excluded assemblies will still be processed correctly.
To do this in the GUI, right-click on the assembly within the package, and select "Exclude assembly from package". Or, if you'd prefer to edit the config file, add the following <option> tag as a child of each relevant <inputassembly> tag:
<option>artifact</option>

The latest Dotfuscator version 4.41.1 has the latest flag
true
This will generate the Dotfuscator config file if the file is missing. Also you can add this to the csproj as documented in the latest getting started guide https://www.preemptive.com/dotfuscator/pro/userguide/en/getting_started_protect.html

Related

Add Zip Files to TARGETDIR in WiX

In my Visual Studio 2017 solution, I have a WiX 3 setup project that pulls in the output several other projects (libraries, executables, assets, content). Under the directory structure for the solution but not added to the solution as a project, I have a project that compiles some browser extensions using webpack. This webpack project outputs to an artifacts folder with subdirectories for each browser. Inside each subdirectory is the compiled extension with the version number included in the file name like:
artifacts
Chrome
myextension-0.1.0.0.zip
myextension-0.1.0.1.zip
myextension-0.1.0.2.zip
At compile time, ultimately I want to include the files matching the version number i.e. myextension-\$(var.VERSION).zip into the MSI package so it can then be placed into the application folder during installation. Even when I hard-code the version number i.e. myextension-0.1.0.2.zip into the component, I get an error from light:
LGHT0001: The system cannot find the path specified. (Exception from HRESULT: 0x80070003)
I'm getting the directory with a define like this:
<?define ChromeTargetDir=$(var.SolutionDir)Extensions\artifacts\chrome\?>
And then my component looks like this:
<Component Id="ChromeExt"
Location="local"
Guid="GUID_HERE">
<CreateFolder/>
<File Id="ChromeExtension"
Name="myextension-0.1.0.2.zip"
Source="$(var.ChromeTargetDir)myextension-0.1.0.2.zip"
KeyPath="yes"/>
</Component>
When I look in the wixobj created by candle, I see the full correct path replaced for the file where it resides on my system:
<field>C:\Users\me\source\repos\mysolution\Extensions\artifacts\chrome\myextension-0.1.0.2.zip</field>
So my question is, what is the correct way to include "arbitrary" files in my WiX project?
1) Solution vs Project Dir: The first thing I would try would be to replace $(var.SolutionDir) with $(var.ProjectDir) and try a recompile. I'll follow up if the problem is something else. Let's just rule that out first.
2) Quotes: I also use quotes around my paths:
<?define ChromeTargetDir="C:\Sources\Packages\MyChromeExtension\Files\" ?>
3) Project Variables: And finally you need a reference added to your project for project references and variables to work: WiX: How to use relative path to SolutionDir.
Maybe add: %ProgramFiles (x86)%\WiX Toolset v3.11\bin\WixUIExtension.dll
WiX Documentation: Using Project References and Variables
Obscure: More obscure causes could be lacking access rights (file not seen by the build process and light.exe - running impersonated?). Corrupted file or folder? (try to replace). And whatever else might conspire against you. Locked files?

Nuget package to include other folders

I am deploying my packages using teamcity and octopus. I am creating packages using teamcity and then using Octopus to deploy to different environments. I have a Resources folder which needs to be copied as a separate step in teamcity. Now I want that folder to be included in the package so I can then deploy that package to remote servers on other domains. I have defined the following file to include resources folder into the content folder of main project. but what's happening is It just create a folder in the destination but don't copy other files with in the project. Please guide as All I want is to include the resources folder with in the package along with my publish website files. I just want the resources folder to be part of package. Please guide
<?xml version="1.0" ?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<id>Services</id>
<version>1.0.0.0</version>
<authors></authors>
<owners></owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Services.nuspec build package</description>
<releaseNotes />
</metadata>
<files>
<file src="..\Resources\**\*.*" target="Content\Resources" />
</files>
</package>
Package contents after creating a package using the above code:-
. _rels
. package
. content\resources
. [content_type
. Services.nuspec
If you're using OctoPack, this behaviour is expected. To quote the documentation on GitHub:
If the <files> section exists, OctoPack won't attempt to automatically add any extra files to your package, so you'll need to be explicit about which files you want to include.
If you go this route, you'll need to specify all the other files you want included within the <files> section of the nuspec.
If you're not using OctoPack, a similar rule applies. See documentation on nuget.org
If you follow the conventions described in Creating a Package, you do not have to explicitly specify a list of files in the .nuspec file. Note that if you specify any files, the conventions are ignored and only the files listed in the .nuspec file are included in the package.
Update
One hybrid method I've seen used is to use the MSBuild Publish target to build & publish the website to a local folder, (to filter out all the compile time files like .cs source), drop in the additional files, and then simply include a <file src="**/*.*" /> to pack everything under the root publish folder. Requires a bit of customisation with root paths / nuget.exe, but it may make the process it a bit neater and slightly less maintenance.
Useful information here that may help you get started.

NUnit not reading the configuration file

I have written a NUnit tests for a .NET application. When I run the NUnit, it does not read the connection string values from the configuration file. I tried many solutions with out success, like
Adding <assembly name>.dll.config file in the path where NUnit loads the DLL file.
Adding the configuration settings in NUnit.exe.config/NUnit.gui.config
I wasn't able to read the configuration setting even when run in VSNunit. Is there a solution?
I've assumed
Assembly being tested: SomeNameSpace.MyClassLib
NUnit assembly with unit tests: SomeNameSpace.MyClassLib.Test
Try this:
Make sure that you have also copied your app.config to your NUnit Test DLL class library (i.e. project SomeNameSpace.MyClassLib.Test) as well.
Build your NUnit Project (e.g. to SomeNameSpace.MyClassLib/bin/debug) and make sure that following are in the bin\debug (or release) directory
the assembly to be tested,
the NUnit test DLL and
the configuration (SomeNameSpace.MyClassLib.Test.config)
any other assemblies needed by your DLL file being tested.
Edit your NUnit Project in the XML view of the NUnit GUI Project editor (menu Project → Edit, or just edit it in Notepad), and make sure that the test assembly (MyClassLib.Test.dll) and the configuration file names are relative to your appbase
For example,
<NUnitProject>
<Settings activeconfig="Debug" processModel="Default"
domainUsage="Default"
appbase="C:\Temp\MyProject\MyClassLib.Test" />
<Config name="Debug" binpathtype="Auto"
configfile="bin\Debug\MyClassLib.Test.dll.config">
<assembly path="bin\Debug\MyClassLib.Test.dll" />
</Config>
<Config name="Release" binpathtype="Auto" />
</NUnitProject>
Add an app.config file to the test project and add your configurations in there.
You then have to tell NUnit what configuration to use as by default it will not pick up the app.config file.
More information on how to set this up with screenshot.
I was stuck on a similar issue for a while. We also need to look at how you are loading the assemblies, based on that the naming of configuration file changes (unless you are using an explicit configuration file from settings). As mentioned here:
http://www.nunit.org/index.php?p=configFiles&r=2.2.10
If a single assembly is being loaded, then the configuration file is given the name of the assembly file with the config extension. For example, the configuration file used to run nunit.tests.dll must be named nunit.tests.dll.config and located in the same directory as the DLL file.
If an NUnit project is being loaded, the configuration file uses the name of the project file with the extension changed to configuration. For example, the project AllTests.nunit would require a configuration file named AllTests.config, located in the same directory as AllTests.nunit. The same rule is followed when loading Visual Studio projects or solutions.

How to add a file to MonoDevelop Packaging project

This seems like a simple question, but I can't find it documented anywhere.
I'd like to add a ReadMe.txt file to the zipped binary archive in my MonoDevelop Packaging project.
I tried this:
<Package name="Linux Binaries">
<Builder targetFile="..\script-keeper-bin-linux.zip" platform="Linux" configuration="Release" ctype="BinariesZipPackageBuilder">
<ChildEntries>
<SolutionItemReference path="..\Keeper.OfScripts\Keeper.OfScripts.csproj" />
<!-- ************************************** -->
<!-- This is where I tried to add the file. -->
<SolutionItemReference path="..\Keeper.OfScripts\ReadMe.txt" />
</ChildEntries>
<ExcludedFiles>
<File>Keeper.OfScripts,ProgramFiles,System.Web.Mvc.dll</File>
</ExcludedFiles>
<RootEntry path="..\Keeper.OfScripts.sln" id=":root:" />
</Builder>
</Package>
But nothing got added (the package did build correctly, but it omitted the ReadMe.txt file).
Is this is same syntax as an MSBuild file? Either way, I can't find anything that helps.
Thanks.
Update:
Well, I thought I set the build-action to Content and properties to Copy to Output Directory for ReadMe.txt, but I didn't. If you set those things, then the file will be included in your package.
Doing so also checks the Include in deploy box in the file's property window.
The way packaging projects work is somewhat strange. The format is not currently compatible with MSBuild, despite the file header. Essentially, a packaging project only includes projects - the list of included projects can be edited in the package options. The files that are included from each project are controlled using the property grid when the files are selected in the solution tree. When the packaging project is built, it can generate several different kinds of package, but they all have the same sources.

Adding first custom Dialog Box to WIX in VisualStudio environment

I'm using Visual Studio to build my wix file. So far I have one file Product.wxs and it's working for a simple install.
Now I want to add some custom dialogs. I think from the two articles below, I understand how to do it - after I get my environment set up:
http://blog.torresdal.net/2008/10/24/WiXAndDTFUsingACustomActionToListAvailableWebSitesOnIIS.aspx
and
http://www.merlinia.com/mdt/WiXTutorial2.msl
I downloaded the source, and I see 35 *.wxs file in this directory
wix35-sources.zip\src\ext\UIExtension\wixlib
This is where I'm starting to get lost.
Do I need to copy some (only the ones I want to change) or all these files to my Visual Studio Project. Until now, I have been running with none of these source files.
How does my Product.wxs know to use these files? Does it look at local directory first? Or do I have to rebuild some C# modules?
I included these lines in my Product.wxs, and it gave me the user interface at execution time:
<UIRef Id="WixUI_Mondo" />
<UIRef Id="WixUI_ErrorProgressText" />
Thanks,
Neal
Do I need to copy some (only the ones I want to change) or all these files to
my VisualStudio Project. Until now, I have been running with none of these source files.
Since you are already using WixUI_Mondo, I assume you want to customize that UI. Locate WixUI_Mondo.wxs in the wix sources, and copy that to your visual studio project. Rename the file to WixUI_MyCustomUI.wxs and change the UI Id attribute inside the file to Id="WixUI_MyCustomUI". You don't need to copy any other files yet; the dialogs referenced in the copied UI sequence are compiled into the wix tools as resources, so wix "knows" these dialogs by name.
In your product.wxs file, change the UI reference to <UIRef Id="WixUI_MyCustomUI" />. If you now rebuild your setup, the UI should still look exactly as WixUI_Mondo as we haven't customized anything yet.
If that worked, you'll probably want to customize or add a dialog. Again, you can start from an existing dialog by copying it from the wix sources. You'll also have to edit the WixUI_MyCustomUI.wxs file so that it uses your new dialog. Take a look at this other answer I wrote for an example.
How does my Product.wxs know to use
these files? Does it look at local
directory first? Or do I have to
rebuild some C# modules?
You do not have rebuild any C# modules. The only reason you downloaded the wix sources is because the existing UI sequences and dialogs are good examples to start from. In principle you could also ignore the wix sources and write these wxs files for the UI sequence and dialog definitions from scratch.
When you use the command line tools, you combine multiple wxs files by simply passing multiple file arguments and they will be compiled and linked together. If you use wix with visual studio, you just have to add the wxs file to the project. A non-trivial wix setup will typically be defined by many wxs files.
The content of a wxs file can container references to elements in other wxs files through elements such as UIRef, ComponentRef, ComponentGroupRef, DirectoryRef etcetera.