the deployproj is a temporary file that is generated from the dproj file every time we deploy the project from the delphi ide. But it's not the case from the command line. I build and deploy my project like this :
MSBuild %ProjectDir%\MyApp.dproj /p:Config=Release /p:Platform=Android /t:Build;Deploy
but if the deployproj not exist (or is not updated), then this command will failed :( Is their any way to generate the deployproj from the command line ?
Related
I am trying to perform a .NET build with MSBuild in Jenkins on a Windows server, and no matter what I do, I get an error MSBUILD : error MSB1009: Project file does not exist.
The command being run correctly defines the name of the sln file, and I have even tried to define the full path to the file with %WORKSPACE%\project.sln, but neither fix the issue.
How can I resolve the problem?
The issue was the default workspace path defined by Jenkins on a Windows OS. It was placing the project files in a path like C:\Windows\System32\config\systemprofile\AppData\Local\Jenkins\.jenkins\workspace\RandomQuotes.
If I ran the MSBuild command from a command prompt specifying the sln file (either with a full or relative path, I got the same MSB1009 error.
If I ran the command without the sln file, I got the error Could not find a part of the path 'C:\Windows\System32\config\systemprofile\AppData\Local\Jenkins\.jenkins\workspace\RandomQuotes'.
I suspect the issue here is the path is too long. The solution was to edit the jenkins.xml file used to launch the Jenkins service and change the JENKINS_HOME environment variable to something like C:\JenkinsHome.
I am trying to create an IPA file from Bamboo by doing this: Firstly I will checkout the default repository, then clone a devops repository, then have a nuget restore task. All of these tasks work perfectly fine but it is the Build for iOS task which is where I create my .IPA file is were I am having the problems. Firstly I am using a command task and the files are being build on a mac-agent(needed to create the .IPA file).
I have tried this two different ways, both ways have different outcomes but basically it is not what I expect to happen. The first way I tried was to use mdtool as the executable which worked like this:
-v build -t:build -p:CustomerApp.iOS *-c:Release|iPhone* CustomerApp.sln
This task will build but the .IPA file will not be created and the log file just says Build for iOS succeeded so I do not know what the problem is for that. The second way that I tried was to use xbuild as the executable which I did it like this:
xbuild /p:Configuration=AppStore /p:Platform=iPhone /p:BuildIpa=true /target:Build CustomerApp.sln
And also tried changing the /p:Configuration=AppStore to /p:Configuration=Release
But both of these responses will return the error
MSBUILD: error MSBUILD0004: Too many project files specified
Note that I know it says error MSBUILD0004 but I am not calling the error the xbuild executable is called with the path: /usr/local/bin/xbuild likewise the mdtool is being called successfully through the path: /Applications/Xamarin Studio.app/Conents/MacOS/mdtool and I have checked that the files exist through the terminal.
What is the reason that the mdtool and xbuild will not create the .IPA file? From what I have seen online it was mainly to do with applications that were not up to date but mine are as shown by the log here:
Already up-to-date.
MSBuild auto-detection: using msbuild version '4.0' from '/usr/local/Cellar/mono/4.6.2.7/lib/mono/4.5'.
All packages listed in packages.config are already installed.
Bamboo is creating a folder which is called MOB-CUSAPP9-JOB1. This is where I want to generate the IPA file from but using that still gives me the error above when using the xbuild way, inside the folder when it is generated it has a file called the CustomerApp.sln which I also tried but got the error as well. Inside the MOB-CUSAPP9-JOB1 files that get created are Mobile.Core.iOS and CustomerApp.iOS I have tried to use all of these and get the same error, I have even tried the whole directory to this but /users/dev/bamboo/etc/MOB-CUSAPP9-JOB1 but got the same result.
Here is an image of the folder that bamboo builds:
During compilation of Delphi project, following error is given by the compiler:
Fatal: F1027 Unit not found: 'System.pas' or binary equivalents (.dcu)
This happens only when building though msbuild using TFS build system.
Works fine when executed through command line as below.
Command:C:\Windows\Microsoft.NET\Framework64\v2.0.50727\msbuild.exe E:\Src\Project\sample.groupproj /v:m /t:Build /p:Config=Release
The following execution through MSbuild fails:
<Exec Command="C:\Windows\Microsoft.NET\Framework64\v2.0.50727\msbuild.exe E:\Src\Project\Sample.groupproj /v:m /t:Build /p:Config=Release"/>
Note:Following env variables are set : BDS,BDSLIB,BDSCOMMONDIR,BDSINCLUDE
When executed through CCNET dcc32.exe has extra arguments such as -I,-LE,-LN,- O,-R,-U,-NB,-NH,but execution through TFS does not have the these argument list.
Any thoughts on how to resolve these errors.
Thanks in Advance....
It is possible that your environment is not configured properly. First call the RSVARS.BAT file located in the BIN directory of your Delphi installation prior to calling msbuild.
If you are calling this from another build system, my suggestion would be to create a simple batch/cmd file that will call RSVARS.BAT followed by executing MSBUILD and have your build system invoke that instead.
If you try to invoke RSVARS.BAT separately, it will modify its copy of the environment then exit, which will effectively do nothing to the parent environment. Adding a call to RSVARS.BAT from within the MSBUILD script will also fail for the same reason. The RSVARS.BAT must be called from the same contextual environment (or higher) as the MSBUILD task.
i am trying to execute devenv.exe through windows batch command plugin in Jenkins
but it keeps on executing and fails to launch the application.
Console Output :
**In progressConsole Output
Started by user anonymous
Building on master in workspace C:\Program Files (x86)\Jenkins\jobs\TEMP\workspace
[workspace] $ cmd /c call C:\Windows\TEMP\hudson3900292017086958332.bat
C:\Program Files (x86)\Jenkins\jobs\TEMP\workspace>set DEVPATH=C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
C:\Program Files (x86)\Jenkins\jobs\TEMP\workspace>set PATH=D:\app\nazopay\product\11.2.0\dbhome_1\bin;D:\app\nazopay\product\11.2.0\client_1;C:\Program Files (x86)\Integrity\IntegrityClient10\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\cde\tools;C:\Program Files\TortoiseSVN\bin;C:\Program Files\Java\jdk1.6.0_23\bin\;C:\Program Files (x86)\Google\Chrome\Application;C:\MingW;C:\PROGRA~2\INTEGR~1\Toolkit\mksnt;%JAVA_HOME%;,;C:\Program Files\Java\jdk1.6.0_23;,;C:\Program Files\Java\jdk1.6.0_23\bin;%CLASS_PATH%;,;C:\Program Files\Java\jdk1.6.0_23\lib;,;C:\Program Files\Java\jdk1.6.0_23\lib;;C:\Program Files (x86)\M**icrosoft Visual Studio 10.0\Common7\IDE
C:\Program Files (x86)\Jenkins\jobs\TEMP\workspace>devenv.exe
You must execute devenv.com.
The devenv.exe always attempts to open GUI, even when commands are given, and it can't. The devenv.com has output directed to standard output and works fine from Jenkins.
You also must pass arguments.
Without arguments both devenv.com and devenv.exe just start the IDE GUI, which is not what you want. The correct command-line is
devenv.com projectname.sln /Build Release /Project projectname
First is path to the solution you want to build. Then the /Build flag is followed by configuration. If you have multiple platforms, you have to pass configuration and platform combination, e.g. Release|Win32. The /Project flag names project to build (including all dependencies). If omitted, it builds all projects selected for build in given configuration.
Why don't you use msbuild?
This would be a good starting point for your windows build script:
call "%VS100COMNTOOLS%\vsvars32.bat"
msbuild projectname.sln /target:Rebuild /l:FileLogger,Microsoft.Build.Engine;logfile=msbuild.log || goto error
goto end
:error
#echo ERROR: Build failed
exit/b 1
:end
exit/b 0
This way you can also capture the output log that you can parse with one of the jenkins plugins.
Ofcourse, adjust the VS100COMNTOOLS to your version of MSVS
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).