I have a requirement to publish a .net desktop application to an on-prem machine which I have now installed VSTS agent on successfully registered. The VSTS release can see the machine OK and it works until downloading the artifact.
I have below settings for Copy files in the Release Definition:-
the settings for Publish Artifact task is :-
I want to copy the build output to a local folder on the designated machine. When release process starts, the artifact is copied to the local machine under vsts work folder OK, however, when the Copy Files process start, it fails with error can't find the folder.
while this folder is available there on C: drive.
Any help is much appreciated.
thanks
Publish Artifacts is the wrong task to use for this. That's intended to be used in your build process.
Just use Copy Files.
Related
I have a strange behavior with msbuild on my Azure Pipeline.
I'm using Azure Pipeline with Self-hosted Windows agents.
Configuration:
My Visual Studio .sln contains two C# projects:
WebService (Rest API)
Business layer
In addition, the Business layer has dependencies on 2 others projects.
Kernel.DataModel
Kernel.DataAccess
The Kernel.DataAcess layer is using the NuGet package "Microsoft.SqlServer.Types" (14.0.314.76)
The Reference "Microsoft.SqlServer.Types" in the project Kernel.DataAccess has "Copy Local = True". Therefore the DLL file should be copied in the output (release) directory.
The problem:
When I run the Azure Build pipeline, the file "Microsoft.SqlServer.Types.dll" is not copied in the "_PublishedWebsites" directory.
To convince myself, I decided to run the same Pipeline on another build machine by changing the Agent Pool. At my surprise the DLL was present in the "_PublishedWebsites" on the second build machine.
Furthermore, I decided to manually run the msbuild command on my local computer and the the DLL was also present in the "_PublishedWebsites...\bin" on my local machine.
Log files:
I also looked at log files on the Build machines and on my local computer.
First build machine -> The DLL file is simply not copied !
Second build machine -> The DLL file is copied from this location.
Copying file from "C:\Program Files (x86)\Microsoft SQL Server\140\SDK\Assemblies\Microsoft.SqlServer.Types.dll" to "F:\AgentLatestBuild\A1\_work\28\b\_PublishedWebsites\ApiProject\bin\Microsoft.SqlServer.Types.dll".
Local machine ->
_CopyFilesMarkedCopyLocal:
Copying file from "C:\TFS\Repos\Src\Project\**packages**\Microsoft.SqlServer.Types.14.0.314.76\lib\net40\Microsoft.SqlServer.Types.dll" to "E:\tfs\build\Microsoft.SqlServer.Types.dll".
Copying file from "E:\tfs\build\Microsoft.SqlServer.Types.dll" to "E:\tfs\build\_PublishedWebsites\ApiProject\bin\Microsoft.SqlServer.Types.dll".
As you can see:
On the second build machine, msbuild is not using the NuGet packages folder but it's using "C:\Program Files (x86)\Microsoft SQL Server\140\SDK\Assemblies\Microsoft.SqlServer.Types.dll"
On my local machine, the DLL is copied from the NuGet packages folder.
Here are my questions:
How msbuild.exe is selecting the source/location of the DLL ?
Is there a way to force msbuild to first use the NuGet packages instead of any others folders ?
I think msbuild should first look in the NuGet packages folder and if the DLL is not found, then it should try to find it from somewhere else. (C:\Program Files (x86), GAC, etc..)
Finally, do you have any idea why the "Microsoft.SqlServer.Types.dll" is not copied at all on the first build machine. The DLL is present in at least three locations. (ie: NuGet packages folder, C:\Program files\ and it is also in the GAC).
It looks like msbuild is lost in the dependency tracking and can't find the file or it won't copy it for some other reasons.
Thanks for your help.
Is it possible that your *.csproj is targetting the wrong HintPath?
Could you check if you have something like this:
<Reference Include="Microsoft.SqlServer.Types">
<HintPath>..\packages\Microsoft.SqlServer.Types.YOURVERSION\lib\net40\Microsoft.SqlServer.Types.dll</HintPath>
</Reference>
thanks
I'm having some issues deploying an Azure WebJob using Visual Studio Team Services (VSTS).
The WebJob seems to be deployed successfully but it breaks the Azure website that is hosted in the same App Service! I don't have this problem if I deploy using VS2013.
This is my build task that generates the WebJob deployment package:
And this is my deployment task:
There are no errors when I deploy the Azure WebJob. If I go to the Azure Portal I see the WebJob is there, and it runs successfully. WebJob files are copied into the wwwroot\App_Data\jobs\triggered\RemoveExpiredDids folder as expected, but the problem is that some other files will be copied into the wwwroot\App_Data\bin folder, which will break the existing website that was already deployed into that App Service!!!
So I decided to find out why this was happening. After downloading and extracting the deployment package I saw there are 2 folders (app_data and bin) and the scheduler file (settings.job):
This explains why some assemblies are coppied into the wwwroot\App_Data\bin of the App Service. The strange thing is that this doesn't happen when deploying from VS2013!!! I took a look into the MSBuild log and found the following line:
Object dirPath ([app service name]\bin) skipped due to skip directive 'SkipBinFolderOnDeploy'.
Concluding, bin folder is included when deploying the Azure WebJob from VSTS but is excluded when deploying it from VS2013.
So my question is: how to prevent the bin folder from being deployed when using VSTS? Is there any MSBuild parameter/flag to do this?
I've had issue with this particular problem as well.
The latest method I found is using Web Deploy Operation Settings , -skip:Directory= (in this case it would be -skip:Directory='\\bin') when you create your azure deploy task in the release definition (Additional arguments). I've seen that this indeed excludes the bin folder from the update actions (result).
Let me know if this helps you in any way.
Refer to these ways to deploy webjob to azure:
Modify Visual Studio Build task to deploy webjob with FileSystem (MSBuild Arguments: /p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:publishUrl="$(build.artifactstagingdirectory)\\WebJob" /p:DeployDefaultTarget=WebPublish)
Add Delete Files task to release definition to delete bin folder (Source Folder: $(System.DefaultWorkingDirectory)/WebJobVnext/drop/WebJob); Contents:bin)
Modify Azure App Service Deploy task (1. Uncheck Publish using Web Deploy option. 2. Package or folder: $(System.DefaultWorkingDirectory)/[artifact name] /drop/WebJob)
I was finally able to fix it, thanks #starain-MSFT for pointing me in the right direction. I had to make some minor changes, though. This is the task that creates the deployment package:
MSBuild arguments:
/p:DeployOnBuild=true /p:WebPublishMethod=FileSystem /p:DeployDefaultTarget=WebPublish /p:Configuration=$(BuildConfiguration) /p:OutputPath=.\bin\ /p:publishUrl="$(build.artifactstagingdirectory)\temp\WebJob"
The difference here comparing to #starain-MSFT answer is that I had to add the /p:OutputPath= parameter, otherwise I'd get the following error:
The OutputPath property is not set for project
After generating the package, I delete the bin folder and zip it (this reduces the build time).
This is my deployment task:
Please note that $(DeploymentPackagePath) is the path to the zip file that contains the deployment package, as mentioned before. It doesn't matter if you deploy the package as a zip file or if you unzip it and deploy the folder, it works both ways.
I am using VSTS (VSO previously) to handle the entire project and would like to do automated releases (builds are already in place) of the website that is not hosted on Azure. Thus I need to use FTP.
As I understand it I should be able to use cURL to accomplish this, but all I have been able to do is transfer all files needed without keeping the much needed file structure.
Has anyone found a way to use FTP to transfer files in the file structure? And if so, how?
You need to use "Batch Script" task and create a batch script to upload the files by curl. Refer to this question for details: Upload folder with cURL and FTP using Batch file on Windows?
If your website is hosted on a Windows Machine, you can use "Windows Machine File Copy" task to upload the files. This task keeps the folder structure.
And also, you can generated web deploy packages during the build by adding following MSBuild arguments in "Visual Studio Build" task in the build definition and upload it to build artifact.
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"
Then in "Release", adding a task to run the "xxx.deploy.cmd" which is included in the build artifacts to deploy the files to your server. (Make sure your server has installed "Web Deploy Remote Agent Service")
xxx.deploy.cmd [/T|/Y] [/M:ComputerName] [/U:UserName] [/P:Password] [/G:UseTempAgent] [Additional msdeploy.exe flags ...]
I am using Visual Studio 2013 to develop a website. The website is on github, and I have a server for continuous integration set up with Teamcity.
I am trying to get the website to automatically deploy to AWS when I change it on github. I have Teamcity hooked up, but the AWS CLI is having some issues, so I need to compile the solution in Teamcity into a zip file so that I can deploy to AWS using a workaround.
I've tried editing the project files for an MSBuild fix...I managed to get a zip file output. However, I ran into problems with general compilation.
What I am wondering is, since I can publish a website package from Visual Studio, is it possible to compile as if I was publishing using the build commands from TeamCity (or the command line) so that the result is the compiled project and the website files needed to run the site in a zip file?
you can create a zipped artifact in TeamCity. Simply build the project then set the artifacts for the build like this:
outputFolder\*.dll=>myzipfile.zip
outputFolder\*.whatever=>myzipfile.zip
etc
obviously you'll need to change outputFolder to be where the files are actually output by the build and the patterns to macth the files you want
We have a TFS build definition set up where we pass the following extra MSBuild arguments in:
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;_PackageTempDir="\\server\build";AutoParameterizationWebConfigConnectionStrings=false
This has been detailed elsewhere as a way to have the published files copied to a specific location instead of generating a deploy package.
This unfortunately does not work on our build server, however if I run the exact same msbuild command line as called by TFS on my dev machine then it works perfectly and copies the output files to the location.
I have checked the log file and there is no errors, it just seems to completely skip the publish/deploy step.
Done building target "_BuiltWebOutputGroupOutput" in project "xyz.csproj".
Target "PrepareForRun" in file "c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets" from project "C:\Builds\2\xyz\xyz build\Sources\xyz.Web\xyz.Web.csproj" (target "CoreBuild" depends on it):
whereas on my local machine, after _BuiltWebOutputGroupOutput target is run the package target runs and deploys the files correctly.
I have tried using different paths and even setting the properties in the project file but it seems to make no difference. My local solution and project files are the same as in the repository that the TFS build is using. Is there something config related on our build server or with the build agent that would cause the packaging target not to run?
I was having a similar problem today and found a fix so it maybe worth a look for you. Here