I have tried creating Android projects and cross platform projects that utilize Xamarin in Visual studio. When I build, even an empty project, it fails instantly without seeming to perform any work.
There are no errors or warnings listed.
The output window has the project name and:
Build: 0 succeeded, 2 failed, 0 up-to-date, 0 skipped
When I start the project I get message boxes warning me about unexpected logger failures and sometimes the dialogs reference the MuxLogger. This is inconsistent, the messages vary slightly and sometimes don't appear at all. Here is an example:
Incidentally I tried manually building to get more output and I get this:
Unhandled Exception: System.TypeLoadException: Could not load type 'Microsoft.Build.Logging.ProfilerLogger' from assembly 'Microsoft.Build, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
at System.Signature.GetSignature(Void* pCorSig, Int32 cCorSig, RuntimeFieldHandleInternal fieldHandle, IRuntimeMethodInfo methodHandle, RuntimeType declaringType)
at System.Reflection.RuntimeMethodInfo.FetchNonReturnParameters()
at System.Reflection.RuntimeMethodInfo.GetParameters()
at System.Diagnostics.StackTrace.ToString(TraceFormat traceFormat)
at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
at System.Exception.GetStackTrace(Boolean needFileInfo)
at System.Exception.ToString(Boolean needFileLineInfo, Boolean needMessage)
at System.Exception.ToString()
at Microsoft.Build.CommandLine.MSBuildApp.Execute(String commandLine)
at Microsoft.Build.CommandLine.MSBuildApp.Main()
Note that I can build many other project types such as web projects and MonoGame projects just fine.
Ultimately this turned out to be a problem with an old version of MSBuild installed in the Global Assembly Cache (GAC). To check for this, first open an instance of Developer Command Prompt for VS2017. Then output the assemblies in your GAC to a file for easy review:
gacutil -l >> someFile.txt
Look for anything that starts with Microsoft.Build, specifically lines that include Version=15.X (hint, these don't output in order so sort the lines alphabetically).
Uninstall all things that start with Microsoft.Build which may include Microsoft.Build.Framework, Microsoft.Build and more. This should not install versions of Microsoft.Build with a version < 15. Command:
gacutil -u Microsoft.Build
and
gacutil -u Microsoft.Build.Framework
This should allow your project to utilize the correct version of MSBuild and compile successfully.
Related
I have just updated a large Xamarin project from MVVMCross version 3.5 to 4.0. I have fixed all namespace issues and bugs, but I am stuck with this bug:
The "LinkAssemblies" task failed unexpectedly.
Xamarin.Android.XamarinAndroidException: error XA2006: Reference to metadata item
'System.Boolean Android.OS.BaseBundle::GetBoolean(System.String,System.Boolean)'
(defined in 'MvvmCross.Droid.FullFragging, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=null') from 'MvvmCross.Droid.FullFragging, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=null' could not be resolved. --->
Mono.Cecil.ResolutionException:
Failed to resolve System.Boolean Android.OS.BaseBundle::
GetBoolean(System.String,System.Boolean)
I have added MvvmCross.Droid.FullFragging.* to linkerConfig.xml, but to no avail.
I experienced the same issue. The MvvmCross dlls are build to version v6.0 for android. I noticed the following output tab (My logging is set to verbose).
warning XA0105: The $(TargetFrameworkVersion) for MvvmCross.Binding.Droid.dll (v6.0) is greater than the $(TargetFrameworkVersion) for your project (v5.0).
When I changed the projects to Android 6.0 I still received the linker error. When I opened the project file in a text editor I noticed that was defined twice. Once in the global property group set to 6.0 and once in the Debug property group set to 5.0. I removed the following line from the Debug property group and the issue went away.
<TargetFrameworkVersion>v5.0</TargetFrameworkVersion>
What you need to do is to switch on verbose logging in your build. For iOS specify verbose logging by adding:
-v -v -v -v
To the extra build parameters textbox. Then run the build again.
For Android you can do this in the Visual Studio Tools -> Settings -> Xamarin -> Android settings -> Xamarin Diagnostics.
You will probably identify that some packages are of different versions and will cause this linking issue.
You will find some clues to the issue using verbose logging. I have only mentioned the verbose logging for this platform as its the platform I have most experience with at the moment.
This is the best answer I can offer as this issue can be caused by a truly massive number of issues and will be individual to each solution.
I have a problem with the standard MSBuild.exe used on our Team Build server, the standard version used is in
"C:\Windows\Microsoft.NET\Framework\v4.0.30319", version 4.0.30319.18408 or
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319" respectively (same version).
Using this version leads to Fake dlls not being generated in the same way as on our local development machines (i.e. some fake methods are missing on the server), resulting in broken builds (unit tests) on the TFS.
I updated the build definition template to use the MSBuild version located under "C:\Program Files (x86)\MSBuild\12.0\Bin" as it is more recent (version 12.0.30723.0), however, this results in an error MSB1025, System.Threading.Tasks.Dataflow, Version=4.5.9.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a not found.
Update
Further investigation - manually adding the System.Threading.Tasks.Dataflow.dll with the correct version number to the MSBuild directory results in a broken build with
Unsupported ToolsVersion 12.0
Manually setting the ToolVersion in the Microsoft.TeamFoundation.Build.Workflow.Acitvities.MSBuild element to "4.0" results in a broken build with
Cannot set unknown member "Microsoft.TeamFoundation.Build.Workflow.Activities.MSBuild.ToolVersion"
So... no real improvement.
Any ideas how to fix this?
Fakes is sensitive to the Visual Studio version. Try passing /p:VisualStudioVersion=12.0 to MSBuild arguments. Also avoid handling System.* assemblies manually.
My team recently tried to upgrade our WorkerRoles project to use Azure 2.5. But I've spent days on it and have had no joy resolving some weird worker role recycling issues and due to time pressure we're rolling back to Azure 2.3.
However, after changing all the references and the app.config file, when I try to run I get the following exception:
System.IO.FileLoadException was unhandled
Message: An unhandled exception of type 'System.IO.FileLoadException' occurred in WaWorkerHost.exe
Additional information: Could not load file or assembly 'Microsoft.WindowsAzure.Diagnostics, Version=2.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I tried changing my app.config bindings, etc. And it seems fine to me. Then I noticed a warning in the error console:
Found conflicts between different versions of the same dependent assembly that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed.
So I ran my build again with the "give me lots of info" setting and I think I've found the issue:
2> Unified Dependency "Microsoft.WindowsAzure.ServiceRuntime, Version=2.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35".
2> Using this version instead of original version "2.3.0.0" in "C:\Users\craig.brett\repos\Admin\WorkersPlus\bin\Craig\WorkersPlus.dll" because AutoUnify is 'true'.
2> Resolved file path is "C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.5\ref\Microsoft.WindowsAzure.ServiceRuntime.dll".
...
2> Unified Dependency "Microsoft.WindowsAzure.Diagnostics, Version=2.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35".
2> Using this version instead of original version "2.3.0.0" in "C:\Users\craig.brett\repos\Admin\WorkersPlus\bin\Craig\WorkersPlus.dll" because AutoUnify is 'true'.
2> Resolved file path is "C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.5\bin\plugins\Diagnostics\Microsoft.WindowsAzure.Diagnostics.dll".
This all looks very suspect to me, when I'm trying to get it to use 2.3. Is there something I need to do to roll back to 2.3? Do I have to uninstall (or attempt to) the Azure 2.5 SDK entirely?
Thanks to Simon Opelt's comment, I went back and did a git diff against the version prior to the update focused on the effected projects.
They revealed that the Azure Caching NuGet package was still at version 2.5, as well as the several sub-libraries of it. There were also a few other Microsoft.* packages that had gone up a few versions. So I used code similar to the following to selectively go through and revert the changes:
git checkout -p <hash of commit prior to Azure upgrade> -- ProjectWorker\ProjectWorker.csproj
git checkout -p <hash of commit prior to Azure upgrade> -- ProjectWorker\packages.config
I took no chances and also rolled back the Azure ServiceBus package.
After this process, things ran fine again! Not quite as easy as it should have been, but at least we're working again and can upgrade at a later date.
I am using Bamboo [from Altassian] and it uses the devenv.com builder to build solution files. Currently, I seem to be getting a "false" error in my builds - that I've tried to solve by myself but just can't - so I thought I would ask.
Each build succeeds normally - without errors stemming from code - but seems to instead give this error
Package 'Microsoft.VisualStudio.TestTools.TestCaseManagement.QualityToolsPackage, Microsoft.VisualStudio.QualityTools.TestCaseManagement, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' failed to load.
I've no idea why this is causing problems in the devenv.com environment and I can't figure out either how to "ignore" this error by some build command?
Try this ( from MSFT support )
Can you check if the dll is in the global assembly cache (open a VS 2010 command prompt
(Start | All Programs | Microsoft Visual Studio 10.0 | Visual Studio Tools))
Type in
Gacutil –l > list.txt
Notepad list.txt
Do you see an entry like
Microsoft.VisualStudio.QualityTools.TestCaseManagement, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL
If so, from the same command prompt, run fuslogvw, go to settings, select log bind failures to disk, select ok
Run your command line
C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.com /Build "Release|Mixed Platforms" "D:\Builds\19\Test VizXView\VizXView v1.8 Test Release Build - Weekly\Sources\VizXView v1.8\VizXView 1.8.sln"
Click on the refresh button in fuslogvw. Do we get any bind errors?
I had a similar issue related to running unit tests on a build server that was using devenv.exe (not devenv.com). I had a premium VS installed on the build server but I'd written the unit tests with ultimate (which 'has' load testing, even tho I'd not used it). I used fusion viewer to work out that the missing dll was LoadTest.dll which I copied from my laptop to the buildserver, I also removed references in my solution that were in version control to: *.vsmdi and *.testsettings (they're deprecated) and I removed from the build def a reference to a .testsettings file.
My guess would be that even though I wasn't running a load unit test the build agent was trying to load the LoadTest libs just in case. Hope that helps
edit ---
ok, my own problem here was that I've got both vs2010 and vs2013 on my laptop. When I added the first test project to my VS2010 solution, the project added actually has a dependency on the 2013 version of the UnitTestFramework.dll. My build server only has vs2010 on it so I got the missing assembly error. Switching the reference to the 2010 version fixed this.
I almost have a NAnt script together that will build and deploy VS2010 database projects, but one error stands in my way:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamData\Microsoft.Data.Schema.TSqlTasks.targets(56,5): error MSB4062: The "SqlBuildTask" task could not be loaded from the assembly Microsoft.Data.Schema.Tasks.Sql, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. Could not load file or assembly 'Microsoft.Data.Schema.Tasks.Sql, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. [xxx]
Failed to start MSBuild.
External Program Failed: C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\msbuild.exe (return code was 1)
I can see that the Microsoft.Data.Schema assemblies are not in the MSIL GAC on the build server - is there any clean way to do this without a full-freight installation of VS2010 on the build server?
For the curious, I asked Barclay Hill at Microsoft who answered this for me:
You can’t build database projects on
machines unless they have VS or TFS
2010 installed on them. It is not a
supported scenario. You can deploy
database project build outputs without
VS/TFS installed using vsdbcmd. The
only way to do this and be in line
with the licensing and support is to
install a local copy of VS Pro or
higher on your build box if not using
TFS.