I am updating my TFS build definition to use nuget restore according to this documentation from Microsoft. My solution builds successfully, but no build output is copied to the drop location. I'm not sure how to determine why. In the MS Build log I see my output being created in the binaries directory, for example:
CopyFilesToOutputDirectory:
Copying file from "obj\Release\ConsoleApp1.exe" to "C:\Builds\4\TestBuild\Binaries\ConsoleApp1.exe".
This is also the same location I see being specified in the Copy Files to Drop Location step of the TFS build log. What am I missing? I am using on premise TFS Version 15.105.25910.0. Is there another way to accomplish what I want?
The problem was with the build template being used by the build definition. The 'Copy to Drop Location' was heavily customized and reading the contents of the ListOfAssembly.txt file to determine copy contents. I changed it a step from another stock template that worked correctly:
<mtbwa:CopyDirectory Destination="[BuildDetail.DropLocation]" DisplayName="Copy Files to Drop Location" Source="[BinariesDirectory]" />
And got the output expected.
Related
I'm trying to use VSTS to deploy into my database, the problem is in one of the steps I need to pick up the dacpac file and deploy it to the Azure SQL server but it fails:
in that step, I'm using "Execute Azure SQL: DacpacTask" which is provided by Microsoft in VSTS.
there is a filed to do it which is called "DACPAC File" and the documentation said to use it like this:
$(agent.releaseDirectory)\AdventureWorksLT.dacpac
but it gave me the below error:
No files were found to deploy with search pattern
d:\a\1\s\$(agent.releaseDirectory)\AdventureWorksLT.dacpac
so I did a cheating and put the below value in it:
d:\a\1\s\AdventureWorksLT.dacpac
it does work but obviously, it won't work forever as I need to use an environment variable, something like :
$(agent.releaseDirectory)\AdventureWorksLT.dacpac
any suggestion?
I've had this same problem. I wasn't able to find detailed documentation, but from experimenting, this is what I found.
I'm assuming that your DACPAC is created as part of a Build Solution task. After the build completes and the DACPAC is created, it exists in a sub-folder of the $(System.DefaultWorkingDirectory) directory.
Apparently, the Azure SQL Database Deployment task cannot access the $(System.DefaultWorkingDirectory) folder. So the file must be copied somewhere where it can be accessed. So here's what I did:
The Visual Studio Build task builds the solution, including the DACPAC. The resulting DACPAC is placed in a $(System.DefaultWorkingDirectory) sub-folder.
Add a Copy Files task as your next step. The Source Folder property should be "$(System.DefaultWorkingDirectory)". The Contents property should be "**/YourDacPacFilename.dacpac". The Target folder should be $(build.artifactstagingdirectory). The "**/" tells VSTS to search all subfolders for matching file(s).
Add an Azure SQL Database Deployment task to deploy the actual DACPAC. The DACPAC file will be in the $(build.artifactstagingdirectory).
I had the same problem and I solved it by removing the old artifact from the release and adding it again to take the correct alias of the new artifact.
That's why the Azure SQL Database Deployment task says it doesn't have access to the $(System.DefaultWorkingDirectory) folder, the artifact has changed and you must make sure you're using the new one that is saved in the azure pipeline.
I have build definition which builds this single solution in source control:
$/MyTeamProject/Dev
So, I use this mapping on the 'Workspace' tab for the build definition:
Source Control Folder: $/MyTeamProject/Dev
Build Agent Folder: $(SourceDir)\Dev
I added a few more projects to this same solution. These other projects exist in a different branch/folder root in source control:
$/MyTeamProject/MyProductName/Dev
So, I added this to the Workspace for the same build definition:
Source Control Folder: $/MyTeamProject/MyProductName/Dev/MyCsProjFolderRoot
Build Agent Folder: $(SourceDir)\MyProductName\Dev\MyCsProjFolderRoot
Build fails with:
C:\Dev\Sources\Dev\AllProjects.sln.metaproj: The project file "C:\Dev\Sources\Dev\..\MyteamProject\MyProduct\Dev\MyCsProjFolderRoot\MyProj.csproj" was not found.
On the build machine, I see the sources downloaded correctly in the structure I expect, but obviously the build doesn't agree.
I reviewed this question: Project file was not found however I am still unclear how to implement this. I am also confused that on the Workspace tab, there is a 'Browse For Folder' button for Build Agent Folder which says 'Please select a local folder.'
Am I going about this all wrong? Do I really need to select a local folder for the Build Agent Folder? (or does that just mean it must be not be a UNC folder - it must be mapped?)?
Solved. It was indeed that the Solution had relative reference to the projects and my workspace mapping wasn't reflecting this exactly.
I am using MSbuild to create a deployment package (simply copying various files from the projects in my solution to different folders) I would like the root folder to be of the format
DeploymentPackage2.3.4.5ForRelease
How can I get MSbuild to put the Assembly number in the folder name automatically?
EDIT:
The solution has a great deal of projects in it (too many really) they all get their version number from a SharedAssemblyInfo.cs file that is manually updated but in the fullness of time will pick up the svn build number (but that is a job for later)
I am building using an external .bat file that calls a custom written .targets/.proj setup that simply calls msbuild on the .sln of the solution.
The 'create package' step I am trying to create happens after a succesful build and will eventually be run by our CI framework, however I would like to be able to run it locally too.
I have created a "CreatePackage" target that does the copying that I want, however it is currently into a fixed folder. I need the folder name to reflect the AssemblyVersion of one of the final dll's.
If there is a better way then I want to know about it... but I am going to use this I think
MSBuild Task to read version of dll
I am trying to update an application that was developed a couple of months ago on VB of Visual Studio 2005.
The "Build output path:" for the project is pointing to a folder in which I collected a few executables related to my activity, BinDir/. It is just next to the project's folder ProjName/ on my disk.
Contrary to the past, when I build my project now, the .exe is created in the ProjName/obj/Debug folder, instead of being directed to the BinDir/Debug folder.
In the IDE's Output tab (while building), the path of the generated executable appears correctly, but in reality it is located somewhere else.
Why is it so?
UPDATE: Something very peculiar is going on my computer today... A couple of hours later I tried again and now it seems like the executable is created in both places. The obj/ version is just redundant now.
What you describe seeing in the Update is what usually happens with Visual Basic builds in Visual Studio 2005. The build creates the executable in an intermediate directory (obj\debug) and then copies the executable from there to the final build output directory (bindir\debug)
With the usual minimal logging turned on, if you examine the build output, you should see the vbc command include the switch /out:obj\Debug\yourproject.exe which tells the compiler to create the executable in the obj\debug fdirectory. Then you should see the file get moved to the build output yourproject -> C:\TestPrograms\Vb.net\yourproject\bin\Debug\yourproject.exe
If you use Tools | Options | Projects and Solutions | Build and Run to set the "MSBuild project build output verbosity" property to "Detailed" you can see a lot more activity against the obj\debug directory and then see the various project output files being copied from that intermediate directory to the build output directory.
The macros $(Targetdir) and $(IntermediateOutputPath) can be used to access these two directories as can be seen using a build event like this...
echo target: $(Targetdir)
echo intermediate: $(IntermediateOutputPath)
In the original question, it sounds like the copy from intermediate to build output either failed or was not attempted leaving you with only one copy of the exe in the intermediate directory.
It's too late to go back and look now but typically the build output window will tell you more about why the copy failed.
I've got a fairly large MVC2 project in TFS which gets built automatically on checkin (Continuous Integration)
At present, the fully built version is dumped on a network share on our dev IIS server. \\Server\wwwrootLatest
TFS of course creates lots of sub-folders since it's just doing a build, it isn't even aware that it's drop directory is a wwwroot.
This means that to actually USE the build, we need to go and manually create an IIS App which points at the appropriate directory - which defeats the whole object of the exercise.
When we do a manual publish to that server, we use "File System" as the method and just overwrite the files in the UNC share \\Server\wwwroot
(When publishing to other environments, we use full-on MSDeploy.)
What I'd like to do is convince TFS to do a "File system" publish after the build completes and duplicate what we do on a manual publish eg:
Drop directory is \\Server\Build which would result in something like \\Server\Build\Project\Date.Rev\
After that is complete, we want it to publish to \\Server\wwwrootLatest - we can then set up the App once which will always contain the latest version but will still have a full history if required.
The only examples I've been able to find use MSBuild commands in the build definition (fine) but all use MSDeploy to do a full-on publish. I'm not sure how to automate what I want to do
Any help appreciated.
In your drop folder a folder named _PublishedWebsites is generated automatically. It contains files you need to put in wwwroot. You can use CopyDirectory build activity to copy them automatically.