How avoid *.<Environment>.config transformations being deployed on server - visual-studio

I'm using VSTS to deploy at several environments. And as usual, some parameters on config files need to be different depending the environment, hence I will use config transformations to deploy it at the target environment.
Since I want to have the package with both the config and the transform that will be applied later I set the Build Action as Content as such:
<Content Include="App_Config\MyConfig.config" />
<Compile Include="App_Config\MyConfig.prod.config">
<DependentUpon>MyConfig.config</DependentUpon>
</Compile>
<Compile Include="App_Config\MyConfig.uat.config">
<DependentUpon>MyConfig.config</DependentUpon>
</Compile>
<Compile Include="App_Config\MyConfig.dev.config">
<DependentUpon>MyConfig.config</DependentUpon>
</Compile>
The package is done correctly and the deploy as well (MyConfig.config has the parameters changed depending on the environment it runs).
My problem is that on the server machine I have the MyConfig.*.config files as well.
Looking at the official documentation example note's (https://learn.microsoft.com/en-us/vsts/pipelines/tasks/transforms-variable-substitution?view=vsts#xml-transformation-example) doesn't give anything clear. It's just "msbuild will do it before packaging and azure not" but doesn't explain a way to do it.
Edit: Solution I went with.
Basically I couldn't avoid to keep the artifacts clean, as they are not dependant on the environment. So after all Release pipeline I added a Delete files job (https://learn.microsoft.com/en-us/vsts/pipelines/tasks/utility/delete-files?view=vsts) To remove all configuration files with the following parameters:
Source Folder:
$(wwwRoot)\
Contents:
**\*.Debug.config
**\*.Release.config
**\*.UAT.config
**\*.PROD.config

You would probably need to think about creating a post deploy script to clean those files and add it to your release script to run at the end of deployment.

First, with XML file transformation, the xx..config file is required.
Secondly, the transform will be applied when publish web app to web deploy package or publish to server directly per to the configuration (e.g. Release, Debug).
Regarding web deploy package, there is xx.SetParameters.xml file, which contains the related transformed elements and the value will be applied during deploy. You can update that file before deploy.
Web.config Transformation Syntax for Web Project Deployment Using Visual Studio
Update:
You also can store the files in Secure Files, then copy the file to related folder through Copy file task:
Download Secure File task
Copy file task (Source folder: $(agent.builddirectory)\..\_temp)

Related

Including Nuget Content Files to Target Projects Publish on .net Core Project

before i start i must state that i pretty new to this nuget package things, so come basic at me.
My app has a core project to carry some .dll and .sql files and an api project. I have made the core project a nuget package with dotnet pack and automated it on github action so it creates a new version at all prs and pushes it to my private nuget server and it is all fine till here.
When i install this core package to my api project, there is no problem either. It installs successfully and my sql files shows up on the target project as i expected(but as linked sources).
But when i try to publish this project with dotnet pack, the .sql files are not copied to output folder. I looked to the properties of the files and saw that their copy to output directory prop has been reset to do not copy and the file path was absolute.
My goal is to build and deploy this api with github actions so absolute paths are not acceptable and besides i don't want to arrange something in the target project manually.
I'm packing the core project with dotnet pack
I don't have any
.nuspec file
package config xml
nuget config
package metadata
or other things like than and i don't know how to use them.
I have tried adding to csproj file <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> and <RestoreProjectStyle>PackageReference</RestoreProjectStyle> things and they did not work.
I have tried adding to csproj file
and it did not work too.
Can anyone help me?
The only thing you need to do is that you should write this node <PackageCopyToOutput>true</PackageCopyToOutput> to every content file of the nuget net core project:
<ItemGroup>
<Content Include="Queries\Account\CheckAccountRef.sql">
<PackageCopyToOutput>true</PackageCopyToOutput>
</Content>
.....
</ItemGroup>
Then, re-pack your nuget project with dotnet pack and then reinstall this new version into your main project. Before you install, you should delete the old caches under C:\Users\xxx\.nuget\packages.
There is a similar issue about this.
You can use .nuspec file to configure all your dependencies. Please refer https://learn.microsoft.com/en-us/nuget/reference/nuspec

Running post deployment script after Web Deploy

I have the following problem and I'm surprised that I can't find any straightforward solution on SO or MSDN.
I have existing *.pubxml profiles in several of my web applications and I would like to execute post deployment script - powershell script - which reorganizes WebSite and its child applications slightly.
I'm not usign Web Deployment Package - just Web Deploy.
The script is deployed successfully but the problem is - how should I execute it automatically after deployment?
I have two scenarios:
Execute by simply "Publish..." from Visual Studio.
Execute as part of TFS Build definition (TFS 2013).
You can try to define a “Target” by MSBuild to achieve your requirement.
For the first scenario:
The Visual Studio build process is defined by a series of MSBuild .targets files that are imported into your project file. One of these imported files, Microsoft.Common.targets. This file contains a set of predefined empty targets that are called before and after some of the major targets in the build process.
So you can define a "Target" element whose "AfterTarget" attribute's value is set to "MSDeployPublish":
<Target Name="CustomPostPublishActions" AfterTargets="MSDeployPublish" >
<Exec Command="..\PostDeploymentScript.sp1 " />
</Target>
For the second scenario:
You can add a PowerShell build task as MrHinsh`s suggestion.
You should switch to deploying from Build & Release only in VSTS/TFS.
You can then add a PowerShell build task and either point at a script or use Inline if it's short. If it is a script that you use in many builds you might want to write your own build task.

setAcl in wpp.targets not performed upon Publish - Web Deploy (but says it is)

I have a web forms application (Visual Studio 2010) with an existing wpp.targets file working successfully to do things like LESS preprocessing, resource minification/bundling, web.config encryption, etc.
I have always been able to deploy just fine by simply right-clicking on the web app, and choosing the Publish - File System option.
I recently decided to try and automate the setting of the ACL permissions on a specific folder within the app. This led me down the road of changing from the File System publish option to the Web Deploy option (which also works fine after installing and configuring Web Deploy 3 on the server).
The reason I switched to Web Deploy is because it's my understanding that by using the Web Deploy option, I should be able to add additional steps to my wpp.targets file to set the necessary folder permissions.
I've seen numerous articles, blogs, forum posts, etc. on the subject and it seems fairly straight forward.
I'm trying to give Read/Write/Modify access to Domain Users for a folder named "IDAutomation" - so I basically just added the following at the end of my existing wpp.targets file:
<Target Name="SetupCustomAcls" AfterTargets="AddIisSettingAndFileContentsToSourceManifest">
<ItemGroup>
<MsDeploySourceManifest Include="setAcl">
<Path>$(_MSDeployDirPath_FullPath)\IDAutomation</Path>
<setAclAccess>Read,Write,Modify</setAclAccess>
<setAclUser>Domain Users</setAclUser>
<setAclResourceType>Directory</setAclResourceType>
<AdditionalProviderSettings>setAclResourceType;setAclAccess</AdditionalProviderSettings>
</MsDeploySourceManifest>
</ItemGroup>
</Target>
<Target Name="DeclareCustomParameters" AfterTargets="AddIisAndContentDeclareParametersItems">
<ItemGroup>
<MsDeployDeclareParameters Include="IDAutomationSetAclParam">
<Kind>ProviderPath</Kind>
<Scope>setAcl</Scope>
<Match>^$(_EscapeRegEx_MSDeployDirPath)\\IDAutomation$</Match>
<Value>$(_DestinationContentPath)/IDAutomation</Value>
<ExcludeFromSetParameter>True</ExcludeFromSetParameter>
</MsDeployDeclareParameters>
</ItemGroup>
</Target>
But I'm obviously missing something because I click Publish -> Web Deploy - and let it do its thing, the permissions are not applied to the folder. The app is deployed successfully and everything looks good - it just doesn't set the permissions on the folder for me.
Here's some excerpts from the end of the deploy output:
Target "Package" skipped, due to false condition; ($(_CreatePackage)) was evaluated as (false).
Target "MSDeployPublish" in file ..... from project .....
Start Web Deploy Publish the Application/package to....
...
Starting Web deployment task from source:manifest(.....) to Destination:auto().
Updating setAcl (Site/app).
Updating setAcl (Site/app).
Updating setAcl (Site/app/IDAutomation). <-- Appears to be doing something??
Updating filePath......
....
Updating setAcl (Site/app).
Updating setAcl (Site/app).
Updating setAcl (Site/app/IDAutomation). <-- Appears to be doing something??
Successfully executed Web deployment task.
Publish is successfully deployed.
Task "MSdeploy" skipped, due to false condition; ($(UseMsdeployExe)) was evaluated as (False).
Done building target "MSDeployPublish" in project ...
Done building project ...
So it appears to be setting the acl on the folder (twice for some reason) as you can see, but when I go look at the folder on the remote server, the permissions have not been applied.
What am I missing here?
I'm not trying to build a package for later/manual deployment or anything involving a build server. I'm simply manually trying to Publish -> Web Deploy.
Also Web Deploy 3.0 is installed on my machine (win7) as well as the web server (Win2008R2/IIS7.5).
-- UPDATE --
I've discovered that regardless of what I set in the setAclUser element, the sitemanifest.xml file is always missing the setAclUser attribute for the folder (abbreviated paths):
<sitemanifest>
<IisApp path="C:\...\obj\...\Package\PackageTmp" managedRuntimeVersion="v4.0" />
<setAcl path="C:\...\obj\...\Package\PackageTmp" setAclResourceType="Directory" />
<setAcl path="C:\...\obj\...\Package\PackageTmp" setAclUser="anonymousAuthenticationUser" setAclResourceType="Directory" />
<setAcl path="C:\...\obj\...\Package\PackageTmp\IDAutomation" setAclResourceType="Directory" setAclAccess="Read,Write" />
</sitemanifest>
So you can see there's no setAclUser on the setAcl element for the IDAutomation folder. Hopefully that will be a clue to someone?
Thanks again-
sigh - Finally realized I was missing the setAclUser property from the AdditionalProviderSettings:
<AdditionalProviderSettings>setAclUser;setAclResourceType;setAclAccess</AdditionalProviderSettings>

How to configure where NuGet.exe Command Tool line looks for packages

We have successfully set up a couple of local package repositories using the NuGet.Server package and hosted them on a local IIS webserver. We are able to connect from the Package Manager and install no problem. So these are working fine.
In order for us not to have to check in our packages folder we have included the following command line in each project file that includes NuGet references. This works, if the NuGet.exe is in the path on the CI build agent.
However, I would like to move the source configuration form the command line in every project file and put it in just one place, preferably where other pesky developers can't change it ;)
<Target Name="BeforeBuild">
<Exec Command="nuget install $(ProjectDir)packages.config -s
http://domain:80/DataServices/Packages.svc/;
http://domain:81/DataServices/Packages.svc/
-o $(SolutionDir)packages" />
</Target>
Is there a better way?
Yes there is ;-)
Take a look at NuGetPowerTools. After running Install-Package NuGetPowerTools, it adds a .nuget folder to your $(SolutionDir) containing nuget.exe, nuget msbuild targets and settings (which you will need to check in).
After that, you simply run Enable-PackageRestore and it sets up msbuild targets into your visual studio project files which will make sure that packages will be fetched in a prebuild step, even on your build server, without checking in any packages. (don't forget to check in the .nuget folder though!).
This way, you simply manage the nuget package sources in a nuget msbuild settings file (in the .nuget folder) central to your solution, instead of in each project.
Cheers,
Xavier
I finally got NuGetPowerTools to install after the advice from digitaltrust on http://blog.davidebbo.com
Although NuGetPowerTools solved my problem, it was overkill for what I wanted. It requires that you check in to version control a .nuget folder that it creates in your solution root. The folder contains NuGet.exe, and a couple of target files. I don't like this as I think version control is for source code, not tools.
I came up with the following solution.
Save NuGet.exe to a folder on your local drive, both on dev and continuous integration machines. I chose C:\tools\nuget\
Add that filepath to the Path Environment Variable in all environments
On continuous integration machines, find %APPDATA%\NuGet\NuGet.Config and enter the following
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="LocalRepositoryName" value="http://Domain/DataServices/Packages.svc/" />
</packageSources>
You can add more than one entry to packageSources and NuGet will search them in the order that they appear
The after build code from my question can now be amended to the following.
<Target Name="BeforeBuild">
<Exec Command="nuget install $(ProjectDir)packages.config
-o $(SolutionDir)packages" />
</Target>
The end result of this is that whenever the approved repository location is changed, the config has to be changed in only one place rather than in every csproj file. Also, it is the continuous integration server administrators who determine that location, not the developers in their command line calls.

Publish web application from MSBuild Script using VS2010 targets resets working directory

I am trying to automatically publish and deploy my .Net 4 web application automatically from a build script to be run by our continuous integration server. I am using the new _WPPCopyWebApplication target from VS2010 to perform the publish, however it appears to reset the current working directory of the msbuild project to c:\ this causes my prebuild steps to fail as they have relative paths to some external tools. The task I am running from our master.build file is as follows:
<Target Name="PublishWeb">
<MSBuild
Projects="$(ProjectPath)"
Targets="ResolveReferences;_WPPCopyWebApplication"
Properties="WebProjectOutputDir=$(DeployPath);OutDir=$(TempOutputFolder)$(WebOutputFolder)\;OutputPath=$(ProjectPath)\bin\Debug;" />
</Target>
This does not happen when using the legacy _CopyWebApplication. Does anyone have any idea how to resolve this problem?
Two possibilities come to mind:
Use the Exec task to call msbuild.exe, and supply a specific working directory.
Your pre-build steps are evaluated by MSBuild and can reference any MSBuild property, so make your paths relative to something specific, like $(MSBuildProjectDirectory), or $(MSBuildThisFileDirectory), instead of just relative to the current directory.

Resources