I'm making an Setup project using WiX and my project uses the Newton.JSON library. I've not referenced the Newton library in WiX however it is fully referenced in my application.
This is the error I'm receiving (Sorry for the image, unable to copy paste the code) :
Could someone please save me, I've been pulling my hair about this for a few hours now, nothing I try seems to work. Tried deleting all bin and ob files, deleted packing.config, deleting the bin and obj from both my project and the installer project. Then trying to reinstall Newton.JSON. Still no joy.
Here is my package.config file currently :
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Newtonsoft.Json" version="6.0.3" targetFramework="net45" />
</packages>
Here is the link to my setup project xml - http://nopaste.info/bcbc2048a6.html (for some reason SO doesnt let me add it as code.
As you can see the packages property does indeed have the newton.json reference.
Anyone have the same issue at all? So it isn't just me?
Try to assemble all dependencies manually in the folder you wish to install to and try to run the application from there to see what files need to be installed. Register any components that need registration such as COM Interop files. Most .NET applications work if you copy all referenced assemblies to the installation directory. The EXE will use the local folder as default search path.
You need to include dependencies in your installer package. WiX doesn't automatically pull in project references.
Related
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
I have a NuGet package (MyPkg) that contains a build target which is dependent on build tasks in another package (AnotherPkg). AnotherPkg has a tools directory with that build task DLL. Following NuGet behavior, the DLL is installed to \packages\AnotherPkg.0.1.1\tools
I am wondering if there is a proper way to reference AnotherPkg's tools path and make it version agnostic. For example, I'd like the package user to be able to upgrade AnotherPkg to 0.1.2, and not have to change anything in my package.
I have some code that kind of works to try and find AnotherPkg's directory... but it seems a little flaky and the project might not load if AnotherPkg has not yet been installed.
<ItemGroup>
<AnotherPkgDll Include="$(SolutionDir)\packages\AnotherPkg.*\tools\AnotherPkg.Tasks.dll" />
</ItemGroup>
<UsingTask AssemblyFile="#(AnotherPkgDll)" TaskName="Whatever" />
Any other tips? I'm hoping I'm missing some sort of NuGet function to get this info.
The package I'm trying to use in my package is on Github. So I modified it and submitted a pull request. :)
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.
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.
In order to simulate the "regasm file.dll /codebase" execution during Install, we run Heat.exe on the file.dll we want to add to registry. Then we add the generated content to our installer.wxs file, and everything works.
We would like to automate the process, so that we don't have to manually run Heat.exe each time the .dll file is changes. Instead, the call will be executed each time we build the Wix project.
How can we do it? A code example will be much appreciated.
Thanks,
Maxim
Are you sure you even need to do this? We have a bunch of ComVisible(true) assemblies in our installer and we did Heat once and never had to do it again. Previously we were using InstallShield which has a .NET Com Interop setting that does similar steps at build time and it was one of our migration requirements to make sure we'd be ok doing this 1 time only when we switched to WiX.
Use heat on the DLL and the TLB to generate DLL.WXI and TLB.WXI files.
Then use something like this in your WXS file to include the XML generated by heat.
<?include DLL.wxi ?>
<?include TLB.wxi ?>