Iam trying to run Heat.exe on TFS build - execution is fine althouth - heat gave me error message:
'C:\PathToplace\Development\Install\WixInstaller\SKRwixInstaller\HarvestedFiles' did not contain any files or sub-directories and since empty directories are not being kept, there was nothing to harvest.
Clear message - before heat i do robocopy task - which should have copied all needed files for harvesting - works fine on local, but on TFS there is no file and any dir, just empty directory i made as well...found this a bit weird...output files are presented in place where they supposed to be - my output location is "as configured". Any idea?
Related
My build fails with
Could not find a part of the path 'App_Data\aspnet-Definiti.Licencing.TestWebProduct-20171016042403.mdf'.
The file exists in in the file system
The file exists in Source Control
The get sources phase seems to find the file fine
2017-11-28T10:49:32.5448880Z Getting aspnet-Definiti.Licencing.TestWebProduct-20171016042403.mdf (no errors here)
Things I've tried:
Excluding the file from the project
Deleting the file in visual studio and checking in
Deleting the file in Source Control Explorer and Checking in
Setting the file to copy if newer
Setting the file to copy always
Unticking build in configuration manager for the offending project
The error always comes back.
Copying App_Data\aspnet-Definiti.Licencing.TestWebProduct-20171016042403.mdf to obj\Release\Package\PackageTmp\App_Data\aspnet-Definiti.Licencing.TestWebProduct-20171016042403.mdf.
2017-11-28T10:50:48.4423213Z ##[error]C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\Web\Microsoft.Web.Publishing.targets(2603,5): Error : Copying file App_Data\aspnet-Definiti.Licencing.TestWebProduct-20171016042403.mdf to obj\Release\Package\PackageTmp\App_Data\aspnet-Definiti.Licencing.TestWebProduct-20171016042403.mdf failed. Could not find a part of the path 'App_Data\aspnet-Definiti.Licencing.TestWebProduct-20171016042403.mdf'.
My final act of sheer desperation was to remove the entire project so at least the rest of the solution would build, but to my utter surprise the error still remains.
The solution was to set the file to do not copy and clear the MSBuild Arguments in the build definition.
I have a CodedUI test suite. I'm attempting to use a B-D-T workflow in TFS 2015 R2 to deploy the test .dlls to a machine group and execute them.
The tests rely on a couple files - an html start page and an XML file.
First, I attempted to have the tests just run from the bin folder OR where they're deployed onto the machines in the machine group. No suggestions I found on SO or on the first 3 pages of google worked. Whenever I ran a test locally it would copy the test dlls to the TestResults folder and execute from there.
Then, I attempted to use a .testsettings file to deploy the files with the .dlls into the TestResults folder. I still truly don't understand why this is the best or only solution - if I can just execute from the Bin please let me know how, but it does work - locally.
Now in TFS 2015 when I deploy my testing software to the test agent(Member of the machine group), I can see my supporting files exactly where they should be in the test drop location. Then, the test starts. A temp folder is created in a byzantine region of AppData, where only the .dlls and config are copied - not the files specified in the .testsettings file! The testsettings file is specified in the "Run Functional Tests" task, which I reached by browsing to the correct file in source control.
I can provide any information you require. This should be so simple but it has been an enormous headache.
In the configuration you need to setup where you copied the files to on the remote machine using a "Windows Machine File Copy" task executed by the agent. You need to make sure all the files needed to run are copied to the server.
Then in your .testsettings file specify which of the files you copied over you want to deploy to the temporary test context directory. Only files already copied to the test agent can be selected here.
The File copy task would look something like:
I'm developing a quality workflow with TFS 2013 and SonarQube 4.5.1. Everything works fine except one thing: I can't integrate code coverage data from TFS to SonarQube. The problem is that SonarQube needs .trx or .cover files to work.
However, my TFS Build doesn't publish those files. What I've done: I created a CodeCoverage.runsettings file that I mapped on my build with "User defined" type. (With CodeCoverageEnabled it doesn't work either.) In the file CodeCoverage.runsettings, I wrote the following XML tag:
<RunConfiguration>
<ResultsDirectory>.\TestResults</ResultsDirectory>
</RunConfiguration>
in the hope that it would write all the results files in the same directory. The build does indeed create the results directories, but none of them contain .coverage files. However, at the end of the build, in the results page, I can download a .coverage file. Do you know how I can force the writing of this .coverage file on the server? When I run analysis on my local config, the file is created in the test results directory.
I seem to be getting a lot of pain with the processing of app.config and token files (we have this working with the older ".11" templates).
It looks like currently (using the ReleaseTfvcTemplate.12.xaml) this is running the tokenisation after the build.
While I can make the app.config / myapp.exe.config stuff work by deliberately copying the .token file into my output folder (so the recursive search finds it) this feels pretty horrid.
As a fix I'm tempted to move lines 182-230 to just before the RunMSBuild task on line 175 (creating a new sequence at that point)
Is this the correct approach or have I missed some documentation somewhere (or a later version of the template?)
Thanks guys... Anyway for future reference I did make the change.
However I had misunderstood the exact nature of the order things happen out of the box which is as follows:
Get the project out of source control
build with msbuild
Copy the .config.token file over the .config file. This is in the TFS template
As part of the deploy to a server then the token entries in the .config files are replaced. This is in the release manager template.
Tests are run in the msbuild binary output folders.
The problem is this doesn't really work if you're using an project type that uses app.config file as the msbuild process renames these output.exe.config during the msbuild stage so you need to create both an output.exe.config (marked as copy to output) and an output.exe.config.token so when the post deploy is the final output gets configured correctly. This also a problem if you want to tokenise some mstest dlls as these typically use an app.config as well. Basically this is a bit of a mess unless you are using web.config.
We worked our way around this by using the modification I suggested above (you need to create a sequence at line 175 and move lines 178-230 up into the sequence, this is GetBuildDirectory variable bits and the if statement) followed by adding an additional deployment stage which copies back onto the build server with the new tokenised files so the mstest can run against them.
So our new process looks like this:
Get the project out of source control
Copy the .config.token file over the .config file i.e app.config.token copied over app.config
build with msbuild (this means we end up with tokenised myapp.exe.config and mytests.dll.config)
As part of the deploy to a server then the token entries in the .config files are replaced. This is a release management step in the release template.
Deploy the tests back into a folder on build server (think this has to be a fixed folder until update 4 of release manager is deployed) the token entries in the .config files are replaced (so our integration tests can use the newly deployed servers). This is a release management step in the release template.
Tests are run in the fixed folder on the build server (rather than the msbuild output directory) so the test wildcard needs to be changed in the tfs build template.
Quick final note we don't use that build directory variable and it's left at blank I'm not convinced this would work if it was set to a value...
The replacement of variables in config files with Release Management happens at deployment time and not at compile time.
When RM deployes your app it inserts the correct variables.
It sounds like you're hitting one of two issues:
You need to include the .token file in your project and make sure it's set to Copy Always, so that it gets copied to the build output folder.
If you're building a web application, I've seen a bug in the release build process template that doesn't touch the contents of the _PublishedWebsites folder. I don't know if it's been fixed in Update 4 or not, but it was definitely still a problem in earlier versions.
Building my solution succeeds, but the build fails upon copying from the build to the drop location. I get an error like this
TF270002: An error occurred copying files from 'E:\Workspace' to '\\server\drop location_20101026.25'.
Details: Access to the path '\\server\drop location_20101026.25\_PublishedWebsites\website\bin\somecompiled.dll' is denied.
This is a part of a continuous integration build (as well as several other types of build that I've tried). This is a copied build definition from a definition that has worked for several months now, running on TFS 2010.
Yep, I was right, I did this myself by putting the copy to drop location task in the parallel foreach loop, resulting in the task being done 3 times, and causing my problems.