We Keep Coding

MSBuild fails for solution with project dependencies

The build for my solution, which contains multiple projects, suddenly appears to be broken and the cause of the issue isn't clear. All of the projects in the solution target the same framework (4.5.1), however, some of the projects' dependencies might be targeting an earlier version of the framework. As of last week, we were able to successfully build solutions that fall under this scenario. Starting last Thursday, the builds appear to be broken without any changes to the build server or the solution.
To illustrate and remove some of the complexities with our production setup, I created a sample solution which mimics the behavior.
Project structure:
CBI Solution
CBI website
CBI Implementation Library
CBI Core library, defining the interfaces
Target Framework Version for the website and class libraries is 4.5.1
Replication Steps
Solution 1
Github repo: https://github.com/NikitaGolovko/Solution1.git
Build, using MSBuild 14. My command is:
msbuild.exe "%SOLUTION1PATH%\CBILite.sln" /p:platform="Any CPU" /p:configuration="Release" /v:d
Output
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v /localhost_61806 -p cbi\ -u -f PrecompiledWeb\lo
calhost_61806\
Microsoft (R) ASP.NET Compilation Tool version 4.7.2046.0
Utility to precompile an ASP.NET application
Copyright (C) Microsoft Corporation. All rights reserved.
Done executing task "AspNetCompiler".
Task "Message" skipped, due to false condition; (!((false) or ('$(AspNetConfiguration)' == 'Debug') or ('$(AspNetConfig
uration)' == 'Release'))) was evaluated as (!((false) or ('Release' == 'Debug') or ('Release' == 'Release'))).
Done building target "Build" in project "cbi.metaproj".
Done Building Project "D:\Work\DotNet\Nikita\Solution1\cbi.metaproj" (default targets).
Done executing task "MSBuild".
Done building target "Build" in project "CBILite.sln".
Done Building Project "D:\Work\DotNet\Nikita\Solution1\CBILite.sln" (default targets).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:03.10
Full output is located here: https://github.com/NikitaGolovko/Solution1/blob/master/MSBuild_Output.txt
Solution 2
Github Repo: https://github.com/NikitaGolovko/Solution2.git
The solution is nearly identical to the Solution1, with the only exception being a dependency for Unity in CBI Implementation library. To simplify the process and eliminate the nuget restore step, I have included nuget packages with the solution.
Build, using MSBuild 14. My command is:
msbuild.exe "%SOLUTION2PATH%\CBILite.sln" /p:platform="Any CPU" /p:configuration="Release" /v:d
Output
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v /localhost_61806 -p cbi\ -u -f PrecompiledWeb\lo
calhost_61806\
Microsoft (R) ASP.NET Compilation Tool version 4.7.2046.0
Utility to precompile an ASP.NET application
Copyright (C) Microsoft Corporation. All rights reserved.
D:\Work\DotNet\Nikita\Solution2\cbi\Index.aspx.vb(5): error BC30002: Type 'CBILite.Calculator' is not defined. [D:\Work
\DotNet\Nikita\Solution2\cbi.metaproj]
The command exited with code 1.
Done executing task "AspNetCompiler" -- FAILED.
Done building target "Build" in project "cbi.metaproj" -- FAILED.
Done Building Project "D:\Work\DotNet\Nikita\Solution2\cbi.metaproj" (default targets) -- FAILED.
Done executing task "MSBuild" -- FAILED.
Done building target "Build" in project "CBILite.sln" -- FAILED.
Done Building Project "D:\Work\DotNet\Nikita\Solution2\CBILite.sln" (default targets) -- FAILED.
Build FAILED.
Full output is located here: https://github.com/NikitaGolovko/Solution2/blob/master/MSBuild_Output.txt
Observations
Bin folder
When looking in the bin folder of the website, I notice that CBILite.dll is missing after the build for Solution2, but present in Solution1.
TargetFrameworkVersion
Passing TargetFrameworkVersion in the MSBuild arguments does not appear to influence the build. I have attempted to pass 4.5, 4.5.1 to no avail. HOWEVER passing 3.5 results in the successful build. This is extremely strange.
Metaproj
When comparing Metaproj files generated for both solutions, the only observable and seemingly important difference is the lack of the TargetFrameworkVersion element. Solution1 (without dependencies), contains v.4.0 element. Solution2 (with the dependency) does not.
I didn't include metaproj files in the repo but can share them if needed.
Visual Studio
Building the solution in Visual Studio works just fine.
Additional thoughts
The issue manifested itself rather suddenly and seems to be affecting most of our solutions that have mixed projects (C#/VB + website). Web Projects continue to function normally.
I've attempted to use MSBuild 15, but it resulted in the same behavior.
There are a few workarounds
Retaining the metaproj file with the solution and modifying it manually by adding v4.5.1 element.
Adding an additional build step to manually copy CBILib.dll into the website project (via the batch file or other means).
Adding a refresh file for the website pointing to CBILib/bin/Release folder
While all of these solutions might work, they're certainly hacks and will present problems in the future.
I'm hoping someone else has a better suggestion on how to handle this.

Make sure you have installed the following NuGet packages:
Microsoft.NET.Test.Sdk
MSTest.TestAdapter
MSTest.TestFramework
Microsoft.NETCore.App (if you use .NET Core)

Upgrading wp8 to wp8.1 silverlight, debugger cannot be launched

I have now had an error with VS2013 and WP8.1 silverlight for a couple of days.
I get a couple of different errors, ..Ensure unlocked screen.., AgHost.exe could not be launched, port is in use by another program and ensure the device is unlocked.
These errors came suddenly after I retarged the solution. I have no compiling errors.
Solution Attempts
Restart PC
Restart program
unregister and reregister the phone
reinstall Update 3
reinstall VS2013
Windows Phone 8 Application crash once its launched AgHost.exe' has exited with code -532265403
Install VS2015 with no luck.
reinstall VS2013 Update 4
Nothing worked. The error is also the same for emulator as well as different devices. I can however get the release mode installed. Break points can be used when using release mode, but I have to Clean, Rebuild and then deploy for every time I want to deploy the application. Further the deploy time has gone up exponentially. Before upgrading I used a maximum of 10 seconds. Now it is above a minute in wait time. :/
Anyone has a solution for this ?
Extra
If I run the solution before upgrade on device or Emulator It spins up with debugger. If then go to the updated WP81, I get a popup with info Something is taking longer then normal and then it crashes with ..Ensure unlocked screen.. :/
Could it be an issue with the differen SDKS?
During a repair of all the SDKs, I found an issue with the event log, which I cleared based on The Event Log File is full
Still no success.
Extra
I cannot spin up the emulator from VS2013, when using the WP8.1 solution, but the wp8.0 solution in the same VS works :S
I found an error in a log file, from:
The errors are:
[0F08:14A8][2015-07-23T09:11:44]: Applying execute package: silverlight5_DRT, action: Repair, path: C:\ProgramData\Package Cache\DEB5078B60B74431E2830831EB48DF129CB32932\packages\Silverlight\5.0_DRT\Silverlight_Developer.exe, arguments: '"C:\ProgramData\Package Cache\DEB5078B60B74431E2830831EB48DF129CB32932\packages\Silverlight\5.0_DRT\Silverlight_Developer.exe" /q /ignorewarnings'
[0F08:14A8][2015-07-23T09:11:45]: Error 0x800705de: Process returned error: 0x5de
[0F08:14A8][2015-07-23T09:11:45]: Error 0x800705de: Failed to execute EXE package.
[0550:0E74][2015-07-23T09:11:45]: Error 0x800705de: Failed to configure per-machine EXE package.
[0550:0E74][2015-07-23T09:11:45]: MUX: Installation size in bytes for package: silverlight5_DRT MaxAppDrive: 0 MaxSysDrive: 0 AppDrive: 0 SysDrive: 0
AND
[0F08:14A8][2015-07-23T09:16:16]: Applying execute package:
{312d9252-c71c-4c84-b171-f4ad46e22098}, action: Repair, path:
C:\ProgramData\Package
Cache{312d9252-c71c-4c84-b171-f4ad46e22098}\VS2012.4.exe, arguments:
'"C:\ProgramData\Package
Cache{312d9252-c71c-4c84-b171-f4ad46e22098}\VS2012.4.exe" -repair
-quiet -burn.related.patch' [0F08:14A8][2015-07-23T09:16:23]: Error 0x80048bc7: Process returned error: 0x80048bc7
[0F08:14A8][2015-07-23T09:16:23]: Error 0x80048bc7: Failed to execute
EXE package. [0550:0E74][2015-07-23T09:16:23]: Error 0x80048bc7:
Failed to configure per-machine EXE package.
Anybody knows what to do with this? The error is coming when I repair Windows Phone SDK 8.0

There was a post-VS2013 update for the Windows Phone 8.1 SDK, some odds that you don't have it installed since you did not need it before. The download location is here.
Getting error messages like "port is in use" when there's no obvious reason why it should be in use and seeing excessive download times is also a very strong selector for your installed anti-malware product getting in the way. No specific advice on how to configure it when we don't know what it might be. You definitely first want to try to temporarily disable it so you can identify it as the source of the problem.

I have no Idea of what is the issue, but creating a new solution and importing the existing projects into a new solution has solved all the issues regarding emulator and debugger an AgHost.
Seems like the upgrade function integrated in the solution did not work properly.

Mono 3.4.1 isn't compiling correctly on the raspberry pi

I m trying to compile the latest Mono source from GIT (3.4.1) on the raspberry pi, i can make, and make install, but if i go to /usr/local/lib/mono i get only “2.0 compat-2.0 gac” folders and none for the other frameworks.
When i try to run:
pi#raspberrypi ~/testeMono $ mcs hello.cs
pi#raspberrypi ~/testeMono $ mono hello.exe
The assembly mscorlib.dll was not found or could not be loaded.
It should have been installed in the `/usr/local/lib/mono/4.5/mscorlib.dll' directory.
I have a initial mono installation that i got doing "sudo apt-get install mono-complete" (since i need mono to build mono) it's on /usr/lib/mono
i did 'make check' and here are the failed tests
420 test(s) passed. 6 test(s) did not pass.
Failed tests:
block_guard_restore_aligment_on_exit.exe
bug-10127.exe
finally_block_ending_in_dead_bb.exe
pinvoke2.exe
pinvoke3.exe
winx64structs.exe
make[5]: *** [runtest] Error 1
make[5]: Leaving directory `/home/pi/mono/mono/tests'
make[4]: *** [testjit] Error 2
make[4]: Leaving directory `/home/pi/mono/mono/tests'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory `/home/pi/mono/mono/tests'
make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory `/home/pi/mono/mono/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/home/pi/mono/mono'
make: *** [check-recursive] Error 1
Any help trying to debug what's wrong is welcome, since i don't know where should i look.

I would add these questions to comment, but don't have enough reputation.
what is the output of ./autogen.sh at the end? Look at the libraries section. Do you have .NET 4.0 and .NET 4.5 'yes' in this section? If they are 'no', try run ./autogen.sh --with-profile4=yes --prefix=your_prefix
Libraries:
.NET 2.0/3.5: yes
.NET 4.0: yes
.NET 4.5: yes
why do you choose to install in /usr/local, when your system mono is located in /usr? You'll have two mono installation in different directories. This is useful, when you what to use parallel mono environments, but as far as I understand, you just want update mono to the latest version. I use --prefix=/usr in this case, to avoid issues of finding libraries in PATH.
these failed tests mean that some of mono functionality (related to PInvoke) won't work correctly on your platform but in general mono will work as expected (because all other tests were passed)

Building ffmpeg on Windows

I've the source code of ffmpeg and would like to build it in my win7. I've minGW installed on my machine. I found a step by step instruction from this link:
http://www.gooli.org/blog/building-ffmpeg-for-windows-with-msys-and-mingw/
The link 'Download updated bash for MSYS' did not follow. It showed the file is not found. When I try to build the program the way explained in the site, it shows an error:
Unknown option “–extra-cflags=-mno-cygwin”.
See ./configure –help for available options.
./myconfig: –extra-ldflags=-Wl,–add-stdcall-alias: command not found
./myconfig: –target-os=mingw32: command not found
From a similar question posted here, I followed the link http://ffmpeg.arrozcru.org/ but the static build downloaded from the site was corrupted. Pls help.

yeah, those instructions are really old, refer to old version of mingw/msys
better, new instructions (visual walk through ) available at http://ingar.satgnu.net/devenv/mingw32/base.html
you install msys, not bash, it comes with MinGW shell, /bin/sh.exe, and you use it to drive configure, just like ingar does with a whole bunch of other projects above
the usual magic incantation is
sh configure --enable-static --enable-shared
make test
make install

MonoTouch - running mdtool from Jenkins

I downloaded the latest MonoTouch (4.0.4.1 and MonoDevelop 2.6 beta) to fix some issues we were having.
I was hoping that my build in Jenkins (using mdtool) would start working, but no luck.
mdtool gives this error (shortened):
2011-07-28 08:18:47.399 mdtool[14484:60f] *** __NSAutoreleaseNoPool(): Object 0x492260 of class NSCFString autoreleased with no pool in place - just leaking
2011-07-28 08:18:47.401 mdtool[14484:60f] +[NSDictionary dictionaryWithContentsOfFile:]: unrecognized selector sent to class 0xa0bdd3ec
2011-07-28 08:18:47.401 mdtool[14484:60f] *** __NSAutoreleaseNoPool(): Object 0x3f02540 of class NSCFString autoreleased with no pool in place - just leaking
In the past this was related to code generation with the designer.
Is this a known issue being working on by Xamarin? (I can open a bugzilla bug if needed)
PS: one thing else to mention, is we have deleted the designer.cs files for several of our views. (This was a crude way to disable code generation at the time, we needed to manually setup our outlets, exports, etc.)
EDIT: posted to bugzilla here.

You are not using the stable version of MonoDevelop, you are using an outdated preview, that was fixed in later betas.