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.
Related
I have build NuGet package consisting of Razor Class Library (RCL) project at .net core 2.2. Once packed I see that it contains static assets that I have configured:
When I install package inside target project, assets refs are visible inside project structure:
But when I try to access them at runtime - i get 404:
https://localhost:44312/localizer-assets/lib/vue/vue.min.js
I see that those files are not "physically" placed inside wwwroot folder (they are iniside package folder).
Is there any way to serve those files? How this should be configured?
So far I have been using those approches:
https://www.learnrazorpages.com/advanced/razor-class-library
Can Razor Class Library pack static files (js, css etc) too?
They work fine when I directly reference RCL project, but when packed with NuGet and installed does not work any more.
They work fine when I directly reference RCL project, but when packed
with NuGet and installed does not work any more.
As far as l know, when you use nuget and choose PackageReference nuget management foramt, the files which targets to import into the main project are introduced into your main project as links(The corresponding files will not exist in the physical path of your solution , but will be linked to the corresponding file address in the %userprofile%\.nuget\xxx). It is the feature of PackageReference nuget management format.
Solution
To solve it, l think you can add a custom build target in the nuget project(Include MSBuild props and targets in a package). With it, you can copy the files from nuget package into the main project.
1.add a target file like .targets or .props(must be the same as the package id) into the \build folder(must be created under the project root directory) of the project. All of these are based on nuget packaging mechanism.
2.add these codes into the target file
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<SourceScriptFiles Include="$(MSBuildThisFileDirectory)..\content\xxxx(relative paths in the current project)" />
</ItemGroup>
<Target Name="CopyScriptsToProject" BeforeTargets="Build">
<Copy SourceFiles="#(SourceScriptFiles)" DestinationFolder="$(ProjectDir)\wwwroot\xxxx\"
/>
</Target>
</Project>
Use a target to copy the file #(SourceScriptFiles) into the main project.(The DestinationFolder is just the destination address).
3.If you use nuspec file to pack your package. You should also add these files under the files node in it.
<files>
<!-- Include everything in \build -->
<file src="build\**" target="build" />
<!-- Other files -->
<!-- ... -->
</files>
In addition, such operation is a pre-build event and when you install the package, you should build your project first and then you will find the file under the destination folder.
Besides, here is a good sample in the github and l hope it can give detailed information and steps.
Hope it could help you.
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
In the past we have used a combination of TeamCity and MsDeploy to deploy our projects. We've recently moved into using Octopus deploy, and TeamCity purely for the Build. This meant changing the build process in TeamCity and removing any references to MsDeploy.
In the past we've used confiiguration such as the below in our project file which included additional files and directories:
<PropertyGroup>
<CopyAllFilesToSingleFolderForPackageDependsOn>
CustomCollectFiles;
$(CopyAllFilesToSingleFolderForPackageDependsOn);
</CopyAllFilesToSingleFolderForPackageDependsOn>
<Target Name="CustomCollectFiles" BeforeTargets="BeforeBuild">
<ItemGroup>
<UCommerceAssemblies Include="$(MSBuildThisFileDirectory)..\..\Resources\UCommerce\ucommerce\*" />
<FilesForPackagingFromProject Include="%(UCommerceAssemblies.Identity)">
<DestinationRelativePath>bin\uCommerce\%(Filename)%(Extension)</DestinationRelativePath>
</FilesForPackagingFromProject>
</ItemGroup>
However this now doesnt seem to get invoked whatsoever. It appears (to me anyhow) that these pipelines were created for use with Publishing from Visual Studio, or using MSDeploy, however we need to just include these files in the directory either before or after the build has taken place. There seems to be tons of references across the web about doing this, however they all refer to using MSDeploy.
Can anyone shed any light on how I can include additional files/directories in the build without using MSDeploy?
Thanks for your time in advance
dotdev
As you are using Octopus for deployment you only need to include additional files (reference assemblies, etc.) into code package sent to Octopus.
To do this one needs to use OctoPack for project packaging. Then add .nuspec file into the project, for example this line in .nuspec will add all files from some different location into the .nupkg package under "bin\additional" and will be deployed correctly by octopus.
Nuspec docs
Similar solution is discuses here.
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.
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.