We are looking to get out of a Virtual Machine and convert a C# MVC website into an Azure Web App. The only hurdle, is that our web application references a C++ project that uses a DLL that has to be stored in the OS's Windows directory. Anyone know how to get around this or any other options?
Use a post-build action in your project, and add the commands to copy the offending DLL. The post-build action are written as a batch script.
The output directory can be referenced as $(OutDir). The project directory is available as $(ProjDir). Try to use relative paths where applicable, so that you can copy or move your project folder without breaking the post-build action.
You needed to copy some dlls to target directory (the build directory) so used the following in a Post-Build event in my project settings:
xcopy $(ProjectDir)openal32.dll $(TargetDir) /Y /D
Here are some commonly used switches with xcopy:
/I - treat as a directory if copying multiple files
/Q - Do not display the files being copied.
/S - Copy subdirectories unless empty.
/E - Copy empty subdirectories.
/Y - Do not prompt for overwrite of existing files.
/R - Overwrite read only files.
Related
I'm running a BAT file from the Pre-Build event of my Delphi projects to update certain files prior to each build. It currently contains hard-coded folder names pointing to the current project's folder. I'd like to try to make this relative to the folder of the current project so I can use the same file for all projects. Is there a way to know for sure what the current directory will be when this file is run? Or is there a symbol in Delphi that represents the folder of the project that I could pass to the BAT file as a parameter?
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.
I have a Visual Studio 2013 solution with the full Orchard source code. When I use "Publish..." on the "Orchard.Web" project in Visual Studio, it correctly publishes the site to the File System destination I've configured into the .PubXml file that I used.
However, if I build this site using Jenkins, the files do not get copied to the destination. I've created a separate PubXml file that is used by Jenkins.
In my Jenkins job, I have two Build steps of interest. The first uses the src\Orchard.sln file with a command line argument of /p:Configuration=Release. This runs correctly, and builds the entire solution.
The second Build step, immediately after, uses the Build File of src\Orchard.Web\Orchard.Web.csproj and these command line arguments:
/p:DeployOnBuild=true
/p:PublishProfile="D:\workspace\Site\trunk\src\Orchard.Web\Properties\PublishProfiles\Jenkins.pubxml"
/p:VisualStudioVersion=12.0
/p:Configuration=Release
/p:Platform=AnyCPU
/v:minimal
/nologo
/p:WarningLevel=1
With this, the build and deploy seems to work - but doesn't. Here are some lines from the build output:
Copying all files to temporary location below for package/publish:
obj\Release\Package\PackageTmp.
Auto ConnectionString Transformed obj\Release\Package\PackageTmp\Shapes\Scripts\Web.config into obj\Release\CSAutoParameterize\transformed\Shapes\Scripts\Web.config.
(... about 200 more "Auto ConnectionString..." lines...)
Finished: SUCCESS
No where does it actually copy the files to the destination defined in the PUBXML file.
In contrast, in Visual Studio, the output looks similar, but transforms only 4 config files and includes lots of "Publishing folder x" lines:
(...)
Transformed Modules\SH.GoogleAnalytics\web.config using ....
Copying all files to temporary location below for package/publish:
obj\Release\Package\PackageTmp.
Publishing folder /...
Publishing folder bin...
(etc.)
(I have installed the latest Windows Azure SDK for .NET on the Jenkins server.)
I have the same trouble,that work for me:
/t:Rebuild
/p:DeployOnBuild=true
/p:PublishProfile=Jenkins_Publish
/p:Configuration=Release
do not use /p:VisualStudioVersion=xxx
This is kind of old, but I actually just set up Orchard to be able to get built via command line and MSBuild. Here is what I did:
/p:VisualStudioVersion=12.0;PublishProfile="example-profile";DeployProjA=true;FrameworkPathOverride="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v4.5";Configuration=Release;PublishProfileRootFolder=c:\Workspace\src\Orchard.Web\Properties\PublishProfiles;Password=ExamplePass
Since you are using Orchard you want to make sure that only the Orchard.Web project gets published so do not use DeployOnBuild=true. This will attempt to deploy every web project in the solution, which is a lot for Orchard. Instead follow the guidelines here to see how to deploy only the web project: http://sedodream.com/2013/03/06/HowToPublishOneWebProjectFromASolution.aspx
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).
As part of my TFS 2010 team build, I'm trying to copy a configuration file from a network location to the output folder where the build goes to.
Using xcopy as an invoke process task, I've successfully gotten it all working EXCEPT that I want to rename the file as part of the copy. The problem is that if you supply a different destination filename, XCOPY asks if the destination is a file or a directory e.g.
XCOPY \\networkshare\configs\live.config \\networkshare\release\server.exe.config /R /Y
results in XCOPY asking me to press F if server.exe.config is a file or D if it's a directory. XCOPY doesn't seem to have any way to suppress this behaviour. I've tried using the basic COPY commmand but Team Build just says that it doesn't recognise the COPY command.
Is there any way to easily rename a file as part of Team Build or use another command line tool to achieve this?
Cheers
Just to confirm - setting the process as CMD.EXE and starting the arguments as "/c copy" does the trick.