I am using TFS2018 and with a step for copying files where the following files and folders should be copied. However the obj folder is always copied as well. How can I prevent the obj folder to be copied?
> *.aspx
> *.ico
> *.js
> *.json
> *.config
> **/app/**/*.*
I just realised I had specified default msbuild arguments in the step. Removing them solved my problem
Related
I am having an issue with building a sln on Jenkins. I know what the problem is I just have no idea how to fix said problem. So the sln imports a project that is not located in the same folder as the sln. This is not an issue with other sln files that we do the same thing with. As you can see below instead of .. to get back to parent directory it is a looking for a .. directory which obviously doesn't exist.
D:\Path\To\sln\OurSolution.sln.metaproj : error MSB3202: The project file
"D:\Path\To\sln\..\..\PathTo\SharedProject\Shared.csproj" was not found
[D:\Path\To\sln\OurSolution.sln]
Edit your .sln file and have it point to the .csproj file that does exist.
Also, double check your working directory to make sure it's the directory where the solution exists.
Paths in the .sln file need to be relative to the location of the .sln file so that when Jenkins can checks out the entire solution into its workspace from source control the paths resolve.
Check that the paths in the solution file are indeed relative to the solution file.
Check that all the project files defined in the solution file (and all their files in turn) are indeed being checked out to the Jenkins job workspace folder.
Where is the shared project in source control in relation to your solution file? Is it in the same repository? If it isn't then my bet is your Jenkins job isn't checking it out from source control into its workspace and therefore not finding it when the solution tries to compile.
Paths your sln and csproj files are relative. .sln and .csproj files paths are relative from where the sit on the file system.
Usually you would expect csproj files to exist in immediate subdirectories of the directory where the .sln file sits.
In a build, we have Copy files from the task. The problem we have is the source folder itself is copied to the destination. We'd want the contents of the source folder to be copied to the destination folder, not the folder itself. Is there any way to do that?
I tried a wildcard but that doesn't work. It seems it needs a path itself. An issue of this could be that the source is named 'X' but the destination is named 'Y' (it was setup before this build and IIS is pointing to this folder). Can we have the source folder be renamed in the build maybe?
That would be name_of_sourcefolder\**\* for all files and subfolders of just name_of_sourcefolder\* for all files.
This has to be set in the Contents part of the task.
IN TFS 2017 on-premises site, I've put together a TFS build that generates several database builds and SSIS package builds. it produces the desired dacpac and ispac files. However, when created, these files are placed in a hierarchy, based on the particular project structure. It looks something like this:
Database1
\bin
\Release
\database1.dacpac
Database2
\bin
\Release
\database2.dacpac
ssisPackage
\bin
\Development
\ssispackage.ispac
I would like to copy all of these files (*.dacpac and *.ispac) to a single
directory (flattened) when pushing them out to my team. However, the Copy Files task is copying them and preserving the folder structure.
The Contents block of the "Copy Files" task is:
**\bin\$(BuildConfiguration)\**\*.dacpac
**\bin\Development\*.ispac
and the Target Folder is
$(build.artifactstagingdirectory)
Is there a way to move this files to the target folder without the folder hierarchy, resulting in:
OutputFolder
\database1.dacpac
\database2.dacpac
\ssispackage.ispac
Thanks for the advice
Refer to these steps to achieve your requirement:
Create a bat file with code below and add to your project, then check into source control (%1 means first argument, %2 means second argument)
Code:
pushd %1
for /r %%a in (*.pdb) do (
copy "%%a" %2
)
popd
Add Command Line build step to your build definition
Note: This code is used to copy pdb files, you need to modify it per to requirements.
in Jenkins, I have a job downloadAgents that is responsible of creating a folder and populating it with some files. Then the folder is saved as an artifact with the following folder structure
dev\downloadAgents\target\dependency\ios
Then I need to copy the contents of the ios folder into the workspace of another job (into a specific folder).
I have added the Copy artifacts from another project step. And it does copy the artifacts, but it copies the full path
\dev\downloadIosAgents\target\dependency\ios
How can I tell jenkins to copy only one folder ios and everything that is inside it and, do not copy all folders that are before ios.
Also if there are already files in the destination folder, will it merge the 2 folders?
You can use regex for your copy (under "Artifacts to copy")-
dev\downloadAgents\target\dependency\ios***.*
** - all folders under ios
*.* - all file types
You can also specify the target directory, and you also have a flag for "Flatten directories". This will move all the files without the hierarchy of the folders (flat to your target directory)
Feel free to look at the plugin's home page:
https://wiki.jenkins-ci.org/display/JENKINS/Copy+Artifact+Plugin
In CopyArtifacts plugin specify the pattern: \dev\downloadIosAgents\target\dependency\ios\*.* or \dev\downloadIosAgents\target\dependency\ios\** - I don't remember exactly.
That should do the job.
The problem: I am setting up TeamCity as a build server for an ASP.NET MVC project. I am using Powershell with psake to run msbuild against our .csproj file and create a deployable package. From the build server, I can open up powershell, run the script and, because there are no source code changes, msbuild does not regenerate the project DLL files. BUT, when I call the exact same script from the TeamCity web interface, msbuild ALWAYS rebuilds and regenerates the DLL files even though there are no changes. Not what it should do AFAIK.
I have narrowed this problem down to a single step. To keep it simple, I have set up my TeamCity config so it is not using any source control, it runs a single "powershell" build step that calls my powershell script.
The powershell script runs a single command:
exec { &$msbuild $ProjectFile /t:Package "/p:PackageLocation=$PackageFile;OutDir=$TempPath;Configuration=$Config;SolutionDir=$BaseDir\Source\" /v:m }
When I call the script manually from a powershell command line, I see:
CoreCompile:
Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files.
When I call the exact same script through TeamCity, I see:
[11:11:26]: CoreCompile:
[11:11:26]: c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Csc.exe /noconfig ...
<SNIP>
[11:11:32]: CopyFilesToOutputDirectory:
[11:11:32]: Copying file from "obj\Demo\Website.Web.dll" to "d:\deploy\Build\package\Demo\temp\Website.Web.dll".
[11:11:32]: Website.Web -> d:\deploy\Build\package\Demo\temp\Website.Web.dll
[11:11:32]: Copying file from "obj\Demo\Website.Web.pdb" to "d:\deploy\Build\package\Demo\temp\Website.Web.pdb".
[11:11:32]: _CopyWebApplicationLegacy:
[11:11:32]: Copying Web Application Project Files for Website.Web
[11:11:32]: Copying file from "obj\Demo\Website.Web.dll" to "d:\deploy\Build\package\Demo\temp\_PublishedWebsites\Website.Web\bin\Website.Web.dll".
[11:11:32]: Copying file from "obj\Demo\Website.Web.pdb" to "d:\deploy\Build\package\Demo\temp\_PublishedWebsites\Website.Web\bin\Website.Web.pdb".
[11:11:32]: Copying file from "d:\deploy\Build\package\Demo\temp\Website.Data.dll" to "d:\deploy\Build\package\Demo\temp\_PublishedWebsites\Website.Web\bin\Website.Data.dll".
[11:11:32]: Copying file from "d:\deploy\Build\package\Demo\temp\Website.Data.pdb" to "d:\deploy\Build\package\Demo\temp\_PublishedWebsites\Website.Web\bin\Website.Data.pdb".
Any ideas why running this script from TeamCity causes msbuild to detect changes and rebuild, but running the exact same script manually does not?
UPDATE:
Thinking this might be caused by some quirk with the TeamCity Powershell runner, I just tried making a batch file that passes the script into Powershell.exe and called it using the Command Line runner:
C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe -NonInteractive -File D:\deploy\Build\run-build.ps1 && exit /b %ERRORLEVEL%
and I get the exact same behavior. If I call this batch file from the command line, the msbuild skips compilation. If I call it from TeamCity, the DLLs are recompiled.
UPDATE #2:
Eureka! I turned on diagnostic debugging in msbuild and found the cause of the forced recompile. It is caused by the GenerateTargetFrameworkMonikerAttribute target. Here is the key bits from the log output:
[15:23:28]: Target "GenerateTargetFrameworkMonikerAttribute" in file "c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets" from project "d:\deploy\source\Website.Data\Website.Data.csproj" (target "BeforeCompile" depends on it):
[15:23:28]: Building target "GenerateTargetFrameworkMonikerAttribute" completely.
[15:23:28]: Output file "C:\TeamCity\buildAgent\temp\buildTmp\.NETFramework,Version=v4.0.AssemblyAttributes.cs" does not exist.
[15:23:28]: Using "WriteLinesToFile" task from assembly "Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
[15:23:28]: Task "WriteLinesToFile"
[15:23:28]: Done executing task "WriteLinesToFile".
[15:23:28]: Done building target "GenerateTargetFrameworkMonikerAttribute" in project "SMM.Data.csproj".
It looks like this target creates/updates an AssemblyAttributes file in the TEMP dir as specified in the TEMP environment variable. Apparently TeamCity overrides the TEMP environment variable and sets it to: C:\TeamCity\buildAgent\temp\buildTmp and this directory is cleaned before every build.
I can see this if I call Get-ChildItem Env: from powershell:
TEMP C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp
TMP C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp
But if I call it from the powershell script as called from TeamCity:
TEMP C:\TeamCity\buildAgent\temp\buildTmp
TMP C:\TeamCity\buildAgent\temp\buildTmp
The key piece is that after this file is regnerated:
[15:23:28]: Building target "CoreCompile" completely.
[15:23:28]: Input file "C:\TeamCity\buildAgent\temp\buildTmp\.NETFramework,Version=v4.0.AssemblyAttributes.cs" is newer than output file "obj\Demo\SMM.Data.pdb".
And this is why the whole project is getting recompiled.
When I run the script from Powershell, the temp directory is not changed or cleaned and the build runs as expected.
So, anyone know how I can either change the directory that this AssemblyAttributes file is created, or tell TeamCity to use a different TEMP dir? I have to believe that this is an issue that others have run into.
Thanks!
So, as I mentioned in "Update #2" above, the problem seems to be caused by 2 things:
- TeamCity sets the TEMP and TMP environment vars to its own temp directory
- TeamCity "cleans" this temp directory prior to every build
- Part of the msbuild process runs a GenerateTargetFrameworkMonikerAttribute target that updates a specific file in the directory specified by the TEMP environment variable - causing the compiler to thing it needs to recompile the whole project
Once I figured this out, I found an applicable answer in this unrelated question:
In Visual Studio 2010 why is the .NETFramework,Version=v4.0.AssemblyAttributes.cpp file created, and can I disable this?
So I added:
<Target Name="GenerateTargetFrameworkMonikerAttribute" />
to both of the projects in my solution that compile to DLLs and it worked.
As a variation of obliojoe's answer, you can backup and restore these files to/from TEMP folder, if you do not want or cannot change the individual project files:
First attempt to restore the files from a backup:
copy temp\*.* %%temp%% /y
echo AssemblyAttributes restore attempted
Then perform your build step(s) using TeamCity build runner
Backup the files:
mkdir temp 2> nil
copy %%temp%%\*AssemblyAttributes.cs temp /y
echo AssemblyAttributes files saved
Both batch files need to run from the same directory.
Do note the final ECHO in these batch files, it is there to guarantee successful exit (error code 0).