MSBuild throws 'name too long' on project if called from Jenkins but not CMD - msbuild

If I run the following command manually everything compiles fine.
cd D:\Jenkins\[redacted]\Api>
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe /property:Configuration=Release Api.sln
If I run the same command (copy/paste) from Jenkins MSBuild gives me the following error for one of my projects
"D:\Jenkins\[Redacted]\Logic\[Redacted].Api2.Logic.csproj" (default target) (26) ->
(GenerateSatelliteAssemblies target) ->
ALINK : error AL1061: Cannot set option 'description' because 'The file name is too long. '
Why does the MSBuild work when running through the CMD but not via Jenkins? It doesn't look like a permissions issue and only one project out of many that hasn't been touched in months breaks.
Even the error message is a little odd - There is no description in the assemblyinfo and there are much longer file names that compile without issues in the solution.
What could be causing this? The best I could find is this http://connect.microsoft.com/VisualStudio/feedback/details/728795/error-al1061-when-building-satellite-assemblies-with-long-names which was of no use.

Related

IntelliJ throws "init terminating in do_boot", but same erl command works in Windows command line

Setup: IntelliJ IDEA 2022.2.2, Erlang 25.0
I am trying to run the Erlang code available at https://erlangbyexample.org/send-receive. I am able to run in werl and Windows command line. But I am getting the error "init terminating in do_boot" when I run in IntelliJ.
I checked a similar issue reported in this question , wherein the solution was to convert list input to integer/s. However, my Erlang code does not expect any input, it just expects the function name.
Please provide a pointer to resolve the issue.
"C:\Program Files\Erlang OTP\bin\erl.exe" -pa F:/1TB/P/workspace-IntelliJ-Erlang1/out/production/workspace-IntelliJ-Erlang1 -pa F:/1TB/P/workspace-IntelliJ-Erlang1 -eval send_recv:run(). -s init stop -noshell
{"init terminating in do_boot",{undef,[{send_recv,run,[],[]},{erl_eval,do_apply,7,[{file,"erl_eval.erl"},{line,744}]},{init,start_it,1,[{file,"init.erl"},{line,1234}]},{init,start_em,1,[{file,"init.erl"},{line,1220}]},{init,do_boot,3,[{file,"init.erl"},{line,910}]}]}}
init terminating in do_boot ({undef,[{send_recv,run,[],[]},{erl_eval,do_apply,7,[{_},{_}]},{init,start_it,1,[{_},{_}]},{init,start_em,1,[{_},{_}]},{init,do_boot,3,[{_},{_}]}]})
Crash dump is being written to: erl_crash.dump...done
I configured RunConfiguration to BUILD before RUNNING ("Before launch" section). As result, RunConfiguration was creating an empty folder "../out/production/workspace-IntelliJ-Erlang1" without .beam files, if the folder does not exist. It would delete any existing .beam files if the folder exists. Hence, the RUN was failing eventually.
As a workaround, I removed the BUILD before RUNNING option from RunConfiguration. And, I manually built using BuildProject before RunConfiguration.
TODO: I will check why was not RunConfiguration able to generate the .beam file.
Check if there is a file called send_recv.beam in either of the directories specified as code path in the -pa arguments. (The undef error means that it can't find the function send_recv:run/0, more often than not because it can't find the compiled module.)
My guess is that this file is actually in the directory where you ran Erlang from the command prompt, but IntelliJ runs Erlang using another working directory. The current working directory is part of the code path by default, which would be why this works from the command prompt but not within IntelliJ.

Index Sources & Publish Symbols step fails in TFS 2015

By default TFS Build creates a "Index Sources & Publish Symbols" step in a Visual Studio Build definition. When the step's property "Path to publish symbols" is empty, everything works fine. But when setting the path to a local directory, the step generates the following error:
2015-09-25T11:00:09.7991491Z Executing the powershell script: C:\NewAgent\tasks\PublishSymbols\1.0.4\PublishSymbols.ps1
2015-09-25T11:00:10.0022755Z Find-Files -SearchPattern **\bin\**\*.pdb -RootFolder C:\NewAgent\_work\990dcb3f\Projects
2015-09-25T11:00:10.0491548Z Found 15 files to index...
2015-09-25T11:00:10.0491548Z Invoke-IndexSources -RepositoryEndpoint <repositoryEndpoint> -SourceFolder C:\NewAgent\_work\990dcb3f\Projects -PdbFiles <pdbFiles>
2015-09-25T11:00:10.6272794Z Invoke-PublishSymbols -PdbFiles <pdbFiles> -Share C:\DebugSymbols -Product EntityMapper -Version 20150925.14 -MaximumWaitTime 7200000 -MaximumSemaphoreAge 1440 -ArtifactName
2015-09-25T11:00:10.7348541Z ##[error]Can't infer artifact type from artifact location C:\DebugSymbols.
2015-09-25T11:00:10.7504779Z
2015-09-25T11:00:10.7504779Z Start: AssociateArtifact
2015-09-25T11:00:10.7504779Z ##[error]Artifact Type is required.
2015-09-25T11:00:10.7504779Z End: AssociateArtifact
The pdb files are published to the specified directory, so i don't really understand what is causing the error (which then causes the whole build job to fail).
When the step's property "Path to publish symbols" is empty, everything works fine.
Yes, because if symbols path is not set, the script only index sources, not publishing symbols.
But when setting the path to a local directory, the step generates the error
You need prepare your symbol store. In your case setup folder sharing and permissions.
In my case changing the "Path to publish symbols" from
//myserver/symbols
to
\\myserver\symbols
solved the issue. Don't know why this happend to me but ok... :)

FAKE error fails in MS.NET build but not Mono

I've got CI builds set up for my project that use MS .Net (with AppVeyor) and Mono (with Travis CI).
The current build has a problem in that it tries to run an executable which is missing. This fails the AppVeyor build:
Starting Target: Run Unit Tests (==> BuildUnitTests, BuildIntegrationTests, BuildSampleApplication)
Running build failed.
Error:
System.Exception: Start of process HttpClient.UnitTests/bin/Release\HttpClient.UnitTests.exe failed. The system cannot find the file specified
at Fake.ProcessHelper.directExec#218.Invoke(String message) in C:\code\fake\src\app\FakeLib\ProcessHelper.fs:line 218
at Fake.ProcessHelper.directExec(FSharpFunc`2 configProcessStartInfoF) in C:\code\fake\src\app\FakeLib\ProcessHelper.fs:line 213
at FSI_0001.Build.clo#68-3.Invoke(Unit _arg3) in C:\projects\http-fs\build.fsx:line 71
at Fake.TargetHelper.runSingleTarget(TargetTemplate`1 target) in C:\code\fake\src\app\FakeLib\TargetHelper.fs:line 411
But the Travis build just carries on regardless, apparently not getting an exception:
Starting Target: Run Unit Tests (==> BuildUnitTests, BuildIntegrationTests, BuildSampleApplication)
Cannot open assembly 'HttpClient.UnitTests/bin/Release/HttpClient.UnitTests.exe': No such file or directory.
Finished Target: Run Unit Tests
(see https://travis-ci.org/relentless/Http.fs/builds/57475713)
This is the code that fails (or not):
ProcessHelper.directExec (fun procInfo ->
procInfo.FileName <- Path.Combine(unitTestsDir, "bin/Release", "HttpClient.UnitTests.exe")
) |> ignore
Any idea why this difference exists, and more importantly how to make it the same on Mono? (In this situation, I'd really like the build to fail). Of course, in this case I could check for the file's existence, but ideally I want the build to fail on any problem.
Edit
The problem, specifically, is that the build does not fail under Mono when I think it should. It seems that the exception which is raised on MS .NET due to the missing exe is either not raised or swallowed on Mono, resulting in a build which passes when it should (IMO) fail.
Looks to me like the file ends up in bin/Debug, not bin/Release.
On line 1244 in the build output you have:
Copying file from '/home/travis/build/relentless/Http.fs/HttpClient.UnitTests/obj/Release/HttpClient.UnitTests.exe' to '/home/travis/build/relentless/Http.fs/HttpClient.UnitTests/bin/Debug/HttpClient.UnitTests.exe'

Running grunt from MSBuild

This thread (Problem capturing error output) gives you a taste of the problem I'm struggling with. I'm trying to run grunt from MSBuild and the grunt errors are not displayed in the Visual Studio output window. I have a .NET project in Visual Studio Express 2012 for Web. I have imported an external project into the project build file with the IMPORT tag and in the imported project I have an Exec task attempting to run grunt. I obviously want to see the error messages that grunt outputs in my Visual Studio output window without too much fuss.
I found an extremely simple workaround that at least sends the output to a text file.
grunt.cmd > grunt-output.txt
This output file is in my .NET project folder somewhere so a quick refresh and double click allows me to open the output file and see a slightly garbled version of the grunt output in Visual Studio.
As an example I'm running a lint task on the grunt.js file, which contains things which JSHint would object to. I deliberately didn't put a semi-colon after var hello and so you get the error message Missing semicolon.
From the command line I get a nicely formatted error message.
Running "lint:files" (lint) task
Linting grunt.js...ERROR
[L2:C10] Missing semicolon.
var hello
<WARN> Task "lint:files" failed. Use --force to continue. </WARN>
Aborted due to warnings.
When I run it from Visual Studio, the output file contains this cluttered format:
[4mRunning "lint:files" (lint) task[24m
Linting grunt.js...[31mERROR[39m
[31m[[39m[33mL2[39m[31m:[39m[33mC10[39m[31m][39m [33mMissing semicolon.[39m
var hello[31m[7m [27m[39m
[31m<[39m[33mWARN[39m[31m>[39m [33mTask "lint:files" failed. Use --force to continue. [39m [31m</[39m[33mWARN[39m[31m>[39m
[31mAborted due to warnings.[39m
Does anyone recognise what all those square brackets and numbers are doing, and can anyone think of a command line switch or grunt switch or node.js switch that would interpret them and turn them into formatting? The don't look like some kind of encoding, they look more like tags to suggest to the command line environment how to format the message. Please don't suggest running some kind of regular expression replace function. I want something quick and easy otherwise it would become more trouble than it's worth.
UPDATE: this link Output gets cut off if piped into another application is pointing to a problem further upstream in node dating back 10 months. While that's getting sorted out it would be nice to at least get a more readable output file.
This thread on the grunt message board Pipe-redirecting Grunt's output is broken addresses this issue perfectly and provides a quick workaround while we wait for the overall issue to get fixed. They are escape codes to colour the output and the workaround is to use the --no-color option to remove colouring.
When I run this command from MSBuild
grunt.cmd --no-color > grunt-output.txt
I get nicely formatted output with exactly the same content as the command line:
Running "lint:files" (lint) task
Linting grunt.js...ERROR
[L2:C10] Missing semicolon.
var hello
<WARN> Task "lint:files" failed. Use --force to continue. </WARN>
Aborted due to warnings.
I can live without the colour. It would be nice if this could be sent to the output window, though, because MSBuild throws what seems like an error in the build process when in fact it's just JSHint tactfully hurting my feelings about my JavaScript.
In response to "I obviously want to see the error messages that grunt outputs in my Visual Studio output window without too much fuss."
I'd have a look at VsCommandBuddy ... it helps you integrate your grunt (and any other command for that matter) right inside visual studio. Commands are configured per solution/project, and at the time of this writing are being made available via menus, toolbar, shortcuts and the quicklaunch ...
http://visualstudiogallery.msdn.microsoft.com/f5da988e-2ec1-4061-a569-46d09733c668
It's a scratch-my-own-itch project. It helps me getting thins done. In every solution I open in visual studio, I simply get presented al the external commands I put togheter for that solution / or porject.
Output goes thorugh the outputwindow as desired. The no-color option for grunt removes all the noise.
Hope it helps!!

help building castle dynamic proxy

So I pulled the source from https://svn.castleproject.org/svn/castle/DynamicProxy/trunk/
Open it up in vs.net 2008
problems:
vs.net can't open the assembly.cs
assembly signing failed
What am I doing, rather NOT doing?
Update
So I downloaded nant, setup the .bat file in my PATH so it works in cmd prompt.
I ran:
nant default.build
Getting this error:
build failed, \buildscripts\common-project.xml (48,3)
invalid element . Unknown task or datatype.
How exactly do I build the dynamicProxy project now?
update
This is what I did, see screenshot:
oh and my nant is:
#echo off
"E:\dev\tools\nant-bin\nant-0.86-nightly-2009-05-05\bin\Nant.exe" %*
http://img697.imageshack.us/img697/5623/castlebuildscreenshot.png http://img697.imageshack.us/img697/5623/castlebuildscreenshot.png
You can read the FM (how to build.txt). :)
You need to run the build script first using NAnt (http://nant.sf.net). This will generate the assembly.cs file. Take a look at the .build files in the tree to see what they are doing.
As for the assembly signing failing, check the project settings to get rid of references to CastleKey.snk. It should sign it using DynProxy.snk (in theory).
UPDATE:
The issue with NUnit is now fixed. Do a clean check out. I really have no idea why you're getting that error. Which version of NAnt are you using? Make sure you have the latest (earlier do not have support for .NET 3.5)
You should be able to just pull the source from the trunk, and build with nant (I just did that and it worked). Ok, I lied, looks like the reference to NUnit is wrong, so the unit test project will not build correctly:
BUILD FAILED - 0 non-fatal error(s), 1 warning(s)
D:\OLD\DynamicProxy\buildscripts\common-project.xml(295,5):
'nunit-console.exe' failed to start.
The system cannot find the file specified
Total time: 1.2 seconds.
BUILD FAILED
Nested build failed. Refer to build
log for exact reason.
Total time: 3.4 seconds.
However the important stuff (assemblyinfo generation) will succeed and you should be able to just open Castle.DynamicProxy2-vs2008.sln, fix the reference to the NUnit assembly hit F5 and build the code with no issues.
I just did it on a clean check out, and it worked.
Generally if you're planning to do modifications in DP codebase, it is advised to go to the Castle user group first, and discuss it there.