I'm working on a pipeline migration from an old manually implemented ci/cd solution to Azure DevOps.
There are some prebuilt functions/processes that I'm still reusing.
For example. Like how they package all their solution as artifacts.
I'm trying to keep the code changes as minimal as possible.
The build pipeline creates a ClickOnce package .zip.
Then on the release stage, the myapp.exe.config in the Application Files gets transformed via XML-Document-Transform. Also the application manifest <ApplicationName>.application gets manually edited through Powershell. The <deploymentProvider codebase="http://1.1.1.1/samplefolder/myapp.application" /> gets changed on release depending on the environment/path it is going to be deployed to.
Application Manifest
<asmv1:assembly ...>
<deployment ...>
<subscription>
<update>
<beforeApplicationStartup />
</update>
</subscription>
<deploymentProvider codebase="http://1.1.1.1/samplefolder/myapp.application" />
</deployment>
</asmv1:assembly>
Now I understand that this method requires Re-Signing of the whole package. They have a custom .exe file to re-sign the whole package (it's not mage.exe). Unfortunately, I cant reuse the said executable to re-sign it.
All I have is their Certificate Thumbprint. But I don't know what to do with it.
Questions:
What are my other options to re-sign the package?
Is there a better way to do this? Do I have to make another build step for this solution?
I have managed to sign the ClickOnce Appmanifest (*.application) and *.exe.manifest files on release by using dotnet mage. I've done this by adding the certificate (.pfx or .p12) file in the Secure Files and the certificate password in the pipeline variables.
Use the .NET Core task specify to use version 5.x.
optional step Re-install via dotnet tool update --global microsoft.dotnet.mage --version 5.0.0
Run the following in powershell
## Signing the exe.manifest file
dotnet mage -update "<folder>/Application Files/<assembly folder name>/<assemblyname>.exe.manifest" -fd "<folder>/Application Files/<folder>" -CertFile "$(SignKey.secureFilePath)" -Password "$(SignKeyPassword)"
## Signing the .Application file
dotnet mage -update "<the .Application full path>" -pu "$publisherURL" -pub "$(PublisherDetails)" -appmanifest "Application Files/<assembly folder name>/<assemblyname>.exe.manifest" -CertFile "$(SignKey.secureFilePath)" -Password "$(SignKeyPassword)"
Related
I have a solution with some projects targeting .NET Standard 2.0 and a console application project targeting .NET Core 2.1.
I set "myFolder" as the output folder.
Building from VisualĀ Studio, I get all DLL files in:
"myFolder\netstandard2.0"
"myFolder\netcoreapp2.1"
I get the same using the "dotnet build" command.
Now I need my console application's EXE file.
So I use the "dotnet publish -c Release -r win-x64 MySolution.sln" command.
Now I get this new directory, "myFolder\netcoreapp2.1\win-x64", where I find all DLL files and the console application's EXE file.
Not enough!
I find one directory more, "myFolder\netcoreapp2.1\win-x64\publish", where I find again all DLL files and the console application's EXE file.
Which meaning do they have? I read the command documentation, but I didn't find my answer.
Per the documentation
-o|--output <OUTPUT_DIRECTORY>
Specifies the path for the output directory. If not specified, it defaults to ./bin/[configuration]/[framework]/publish/ for a framework-dependent deployment or ./bin/[configuration]/[framework]/[runtime]/publish/ for a self-contained deployment.
dotnet publish -c Release -r win-x64 --output ./MyTargetFolder MySolution.sln
All you really need to understand to be able to successfully publish and deploy is that you need to dotnet publish and ensure that you have a Release configuration -c Release, as well as any other required options on the command line.
All of your files will be in the 'publish' subfolder, e.g. ./bin/Release/[framework that your solution is targeting]/publish. The files contained here are everything that is needed for a running instance of your application/service. The MySolution.dll is the entry point for your app/service, and will automatically link to all of the other dependencies and configuration stored in the publish folder.
To configure and deploy a running instance, you need to work out how to deploy all of those files to a server, and somehow configure something (e.g. a web server, runtime, service host ...) to call your MySolution.dll.
Note that in your dotnet publish you're specifying -r, which means that your application is targetted to run under 64 bit Windows, as opposed to a Linux distribution or OSĀ X (which makes it less portable, but it has the advantage of isolating your application from changes to an installed runtime on a server that you deploy it to.). That's why you're seeing an extra folder win-x64.
Also you're explicitly building from the solution configuration specified by your solution file MySolution.sln, which is probably the most reliable thing to do as this will ensure that any projects used as dependencies by your solution (which is a typical good practice) will be included in the build/publish.
I am developing an ASP.NET core application.
I use VSTS online for my source control. I also have a dedicated machine to build the application.
To automate the process, I am now trying to define a build script from VSTS online.
The default VSTS template defines many tasks. I removed all the unneeded tasks for my purpose and am down to just three tasks - "Use NuGet," "NuGet Restore," and "Build Solution."
The default msbuild argument for "Build Solution" task is:
/p:DeployOnBuild=true /p:WebPublishMethod=Package
/p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true
/p:DesktopBuildPackageLocation=
"$(build.artifactstagingdirectory)\WebApp.zip"
/p:DeployIisAppPath="Default Web Site"
Although there is no error in running this script, I need to change it such that the output goes to a folder and is not packaged.
Here is part of my directory structure that is relevant for my question:
C:\Dev\RCWebsite\RCWebsite.sln
C:\Dev\RCWebsite\RCWeb\RCWeb.csproj
C:\Dev\RCWebsite\RCWeb\Properties\PublishProfiles\FolderProfile.pubxml
Here is the content of the publish profile:
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<PublishProvider>FileSystem</PublishProvider>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<ExcludeApp_Data>False</ExcludeApp_Data>
<ProjectGuid>d7d9f3b7-fd0e-49c1-b6d2-3af5dddb6699</ProjectGuid>
<publishUrl>C:\StagingSites\rcweb</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
</PropertyGroup>
From the console window, I can run the following command:
msbuild .\RCWeb\RCWeb.csproj /p:DeployOnBuild=true
/p:PublishProfile=RCWeb\Properties\PublishProfiles\FolderProfile.pubxml
This works as expected. The final output is generated in C:\StagingSites\rcweb\ directory.
As this command works, I replaced the msbuild argument in VSTS "Build Solution" task as:
/p:DeployOnBuild=true
/p:PublishProfile=rcWeb\Properties\PublishProfiles\FolderProfile.pubxml
Note that I haven't specified .\RCWeb\RCWeb.csproj as an argument. Guess the build mechanism automatically takes care of this.
When I run this build and look at the log file, I see that the solution is built fine. However, it is never copied to C:\StagingSites\rcweb\ directory.
Can someone please tell me what is it that I am missing? Do I need another "deployment" task after "build solution" task? Regards.
Although there is no error in running this script, I need to change it such that the output goes to a folder and is not packaged.
No you do not need another deployment task. Since you do not need to package and deploy the ASP .NET project with msbuild, you can get rid of the /p:DeployOnBuild=true flag to msbuild. Also, after having a look at your publish profile I realized that you aren't really passing any information to msbuild (nothing that can't be passed from msbuild parameters atleast) and since you no longer plan to directly deploy from msbuild, it would be a good idea to keep the publish profile aside.
After trimming down the parameters and adding a few necessary ones (/T:Package tells msbuild that you want to package the binaries but not deploy them), this is what your msbuild command would look like:
/p:OutDir=$(Build.BinariesDirectory) /T:Package /p:PackageLocation=$(Build.BinariesDirectory)\WebApp.zip /p:PackageAsSingleFile=true
This is assuming that you wish to have a .zip file that is ready to be deployed, as the output. If that's not the case and you just require the binaries in a folder that can be directly deployed but not zipped, you can use the below command:
/p:OutDir=$(Build.BinariesDirectory) /T:Package /p:PackageLocation=$(Build.BinariesDirectory)\WebApp.zip /p:PackageAsSingleFile=true p:_PackageTempDir=$(Build.BinariesDirectory)\MyAspNetWebsite
This will generate the zip as well as the binaries folder ready to be deployed (sadly you need the zip for the temporary dir flag to work)
NOTE: If you plan on using the msbuild command within a powershell script, the VSO variables will need to accessed in a different way, like so: 'BUILD_BINARIESDIRECTORY'
I've just started trying to configure a CI/CD process using Visual Studio Team Services, with a view to having a gated check-in process which then automatically packs and pushes the output to a private NuGet Feed. I'm successfully getting through the "Get Sources" task which exists natively in the build definition, however my package task is failing at this stage:
d:\a\_tool\NuGet\4.0.0\x64\nuget.exe pack
d:\a\1\s\Core\Core\Core.csproj -NonInteractive -
OutputDirectory d:\a\1\a -Properties Configuration=$Release;OutDir=$(OutDir)
-Symbols -version 1.0.0-CI-20170811-095629 -Verbosity Detailed
NuGet Version: 4.0.0.2283
Attempting to build package from 'Core.csproj'.
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin\amd64'. Use option -MSBuildVersion to force nuget to use a specific version of MSBuild.
NuGet.CommandLine.CommandLineException: Unable to find 'd:\a\1\s\Core\Core\$(OutDir)\Core.dll'. Make sure the project has been built.
Essentially, the 2nd line of the log demonstrates that my project file is in d:\a\1\s, however the output is directed to d\a\1\a - not the same place. The instruction to NuGet to package my file then looks in the correct location (d:\a\1\s), but the file isn't here.
I understand that I can specify a Package Folder within the build definition, however I've not changed this from the default ($(Build.ArtifactStagingDirectory)) - I expect this to work natively, but for reasons I can't explain, it's not.
Is there a token or wildcard I can provide in an additional build property that will rectify this? I've taken the guidance of the first posted answer in here and changed $(Build.ArtifactStagingDirectory) to $(Build.Repository.LocalPath), which gets me much closer to the goal as the error now reads -OutputDirectory d:\a\1\s\... - I've tried manually putting a variety of sensible paths no the end of this, but the error persists.
Refer to this article. It has the build variables for the TFS/VSTS environment.
$(Build.ArtifactStagingDirectory) itself refers to the \1\a folder. You might want to try the $(Build.Repository.LocalPath) variable.
Not a 100% if it would work, but might as well try.
The issue is related to OutDir=$(OutDir) instead of OutputDirectory.
The OutputDirectory specifies the folder in which the created package is stored and the OutDir specifies the build output, but the project need to be built before NuGet pack task, so you need to add Visual Studio Build task or related to build project.
You can leave Additional build properties box blank to use default output per to configuration, because you just need to know the package stored path to push package to remote feed.
If you want to change build output, you can specify /p:OutDir msbuild argument to change build output location. For example:
Visual Studio Build task (MSBuild Arguments: /p:OutDir=$(Build.ArtifactStagingDirectory))
NuGet pack task (Additional build properties: OutDir=$(Build.ArtifactStagingDirectory))
BTW, to change package stored location, you need to specify OutputDirectory.
I am using ClickOnce application deployment, and I just got my code certificate from Verisign. I am using this certificate to sign the manifest.
When I download and install the application, the smartscreen comes up with my name on it (lame, but I think this is what is supposed to happen). When the ClickOnce installer completes, the smartscreen comes up again for the execution of the actual application, here it says 'Unknown Publisher'.
Does ClickOnce not sign the assemblies by default? How do I do this?
Edit: Currently I am letting VS sign my manifest (installer) for the ClickOnce, and I am setting a Post-build event to sign my assembly. But still when I install the application it says 'unknown publisher' when I go to actually run it.
That does not sound right to me. I have used exactly the same workflow for multiple applications, and it works fine. Most likely there is an issue with your postbuild step. Make sure that you sign EXE file inside the OBJ folder (because that's where ClickOnce takes all the files from) - not the BIN one.
Do ClickOnce publishing, go to the OBJ folder, right click on your application.exe file, and select properties. It should have six tabs - the last one being "Digital Signature":
If you don't have it, you don't sign your application properly.
And here is my postbuild step - note that I sign "RELEASE" configuration only:
<Target Name="SignOutput" AfterTargets="CoreCompile" Condition="'$(ConfigurationName)'=='Release'">
<PropertyGroup>
<TimestampServerUrl>http://timestamp.verisign.com/scripts/timestamp.dll</TimestampServerUrl>
<ApplicationDescription>my app</ApplicationDescription>
<SigningCertificateCriteria>/n "my company."</SigningCertificateCriteria>
</PropertyGroup>
<ItemGroup>
<SignableFiles Include="$(ProjectDir)obj\$(ConfigurationName)\$(TargetName)$(TargetExt)" />
</ItemGroup>
<Exec Condition=" '$(ConfigurationName)'=='Release'" Command=""c:\Program Files (x86)\Windows Kits\8.0\bin\x64\signtool.exe" sign $(SigningCertificateCriteria) /d "$(ApplicationDescription)" /t "$(TimestampServerUrl)" "%(SignableFiles.Identity)"" />
</Target>
So I am trying to use TFS Build for generating deployment packages for my 3 environments (ST, UAT, Prod).
This what I followed to successfully genrate the package locally.
http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/74bb16ab-5fe6-4c00-951b-666afd639864/
So my local machine will generate the package for the acyive configuration and everything is good. Here is my Build definition :
/p:DeployOnBuild=true;DeployTarget=Package
I run my solution file and the web deployment project in the Projects To Build.
It creates the respective folders with ST, UAT and PROD. In each of these there is a _PublishedWebsites folder. This folder have 2 folders.
1) MydeploymentProject - It contains the transformed web.config
2) MyDeploymentProject_Package - Contains the Package folder contents along with the zip file and setparameters files. Here the everything is not transformed. But if I check the TempBuildDir on the TFS server it does contain the transformed config.
When compared the logs local and on server, I found that the on my local After transformation files are updated and package is created whereas on TFS the AfterBuild target is called transformation done and it ends there.
this is my local log
Target "WPPCopyWebApplicaitonPipelineCircularDependencyError" skipped, due to false condition; ($(WPPCopyWebApplicaitonPipelineCircularDependencyError)) was evaluated as (False).
Target "ProcessItemToExcludeFromDeployment" in file "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" from project "C:\TAX-IT\Main\Source\TDDB\TDDB_deploy2\TDDB_deploy2.wdproj" (target "PipelineCollectFilesPhase" depends on it):
Done building target "ProcessItemToExcludeFromDeployment" in project "TDDB_deploy2.wdproj".
Target "GetProjectWebProperties" in file "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets" from project "C:\TAX-IT\Main\Source\TDDB\TDDB_deploy2\TDDB_deploy2.wdproj" (target "PipelineCollectFilesPhase" depends on it):
Using "GetProjectProperties" task from assembly "C:\Program Files\MSBuild\Microsoft\WebDeployment\v10.0\....\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll".
Task "GetProjectProperties"
I am not sure what is wrong.
Also I installed VS2010, web deploy 2.0 and 3.0 and web deployment tools on my Build servers.
Anyone have faced this and resolved.
Please help.
Thanks
MadCoder,
From what I've gathered from your description, you have everything set up correctly. It seems like you are just missing the "Configuration" parameter. When you do run the Build Definition, it uses the configuration specified in your "Configurations to Build" argument. If you want to have multiple configurations built (like you are suggesting), you'll need to have multiple configurations defined. One question I have is: When you look at the logs of the TFS Build Process, do you see multiple configurations built, or do you only see one? If you only see one, then you don't have all of the configurations defined in order to transform the config file. According to your description, you'll need to see something like this in your build definition configuration:
If you don't want to deploy to a webserver, you can stop reading here, and don't have to continue on.
If you choose to use a TFS Build Definition to deploy to a web server, you'll need to have a target web server somewhere and you'll need to install and configure the Web Deploy v2/v3 on that server as well.
When you are using TFS Build Definitions to deploy, the transformation happens upon deployment, not during packaging (prior to deployment). It may package up a transformed config somewhere, but it won't actually transform the config bundled with the website. The only way I've been able to get the deployment to actually work with a transformed config is when I had a website specified in the MSBUILD args. Here is an example of my MSBUILD args:
/p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:MSDeployPublishMethod=RemoteAgent /p:MsDeployServiceUrl=MyWebServer/MsDeployAgentService /p:DeployIisAppPath="MyWebsite as named in IIS" /p:UserName=MyDomain\MyWebDeployUser /p:Password=MyWebDeployPassword
If you don't want MSBUILD to do the actual deployment (I prefer not to because then your deployment process is tied to TFS), you can do the deployment after the build process and use the CTT Project, found on codeplex. This tool performs the exact same transformations as MSBUILD, but it also includes the ability to parameterize settings so you can define classes of environments (for example, 3 QA environments, 2 Staging Environments, etc.) and still use the respective transforms for that class of environment.