We Keep Coding

Mobile Center UITest exit code 20

I've been trying to run a UI test via Visual Studio Mobile center for a while now, but I'm getting the following error:
Preparing tests... failed.
Error: Cannot prepare UI Test artifacts. Returning exit code 20.
I looked on the mobile-center-cli github page and found that error codes 1 until 63 are reserved for TestCloud. There is really no documentation about this error so I hope someone is able to point me into the right direction.
Command used:
mobile-center test run uitest --app "MyAppName" --devices d5c95903 --app-path "pathToApk" --test-series "master" --locale "en_US" --build-dir "PathToBinRelease"

It sounds like you may be specifying the wrong folder for your --build-dir.
The --build-dir should be the bin/Debug folder of your Xamarin.UITest project, something like this:
"/Users/User/AppSolution/App.UITests/bin/Debug"
Can you please try the above and let me know if it resolves the issue?
Glenn

Another reason for this error is if there is more than one version of Xamarin.UITest present in the packages folder, that is visible in the root of your project.
Remove the unnecessary versions of Xamarin.UITest and give it another go.

I had this error. I added this param to my script:
--uitest-tools-dir "...your_path\packages\Xamarin.UITest.2.0.10\tools"
This is work for me.

--uitest-tools-dir $APPCENTER_SOURCE_DIRECTORY/packages/Xamarin.UITest.*/tools
https://tomsoderling.github.io/AppCenter-Automated-UI-tests-on-build/

Teamcity, MSBUILD ExtensionPack.Framework.AssemblyInfo task fails

It seems like everything has broken overnight at the same time... sigh.
In a desperate attempt to fix other random problems I need to make a build of our large project only to find that our teamcity build agents can no longer do their job. The error message is below:
[CallTarget] Version (1s)
[Version] MSBuild.ExtensionPack.Framework.AssemblyInfo (1s)
[MSBuild.ExtensionPack.Framework.AssemblyInfo] I:\BuildAgent-DEVTC1\work\e7d35660eba50bd6\build.proj(150, 3): error MSB4018: The "MSBuild.ExtensionPack.Framework.AssemblyInfo" task failed unexpectedly.
System.ArgumentNullException: Value cannot be null.
Parameter name: input
at System.Text.RegularExpressions.Regex.Matches(String input)
at MSBuild.ExtensionPack.Framework.Version.ParseVersion(String version) in D:\Projects\MSBuildExtensionPack\Releases\4.0.3.0\Main\Framework\Framework\AssemblyInfo\Version.cs:line 51
at MSBuild.ExtensionPack.Framework.AssemblyInfo.Execute() in D:\Projects\MSBuildExtensionPack\Releases\4.0.3.0\Main\Framework\Framework\AssemblyInfo\AssemblyInfo.cs:line 1011
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
The proj definition for the Version target is the following where #VersionDefinition is an "inlcude" for all AssemblyInfo.cs files:
<Target Name="Version">
<MSBuild.ExtensionPack.Framework.AssemblyInfo
AssemblyInfoFiles="#(VersionDefinition)"
AssemblyVersion="$(BUILD_NUMBER)"
AssemblyCopyright="Copywrite info here"
AssemblyCompany="Company info here"
AssemblyFileVersion="$(BUILD_NUMBER)"/>
</Target>
I can see that teamcity is correctly passing in BUILD_NUMBER with a valid value too.
Any ideas?
I'm open to suggestions that don't rely on the extension pack to set AssemblyInfo.cs numbers. I have looked into the TeamCity Assembly Info Patcher but I wasn't sure what "standard locations" was referring to in its description.
On a side note, have there been any updates recently to windows or .NET that could have broken everything...everywhere? I have recently had numerous third party libraries start to fail, almost simultaneously.
Thanks
UPDATE
The logs for recent successful build do not even show the Version target being called... which is odd given that that's the only place the correct build number is set and the build created files with the correct number applied.

So I installed a newer version of the ExtensionPack (4.0.13.0) on to the build clients and got a slightly clearer error message that told me which file was at fault.
Examining the AssemblyInfo.cs file mentioned the AssemblyVersion and AssemblyFileVersion values were missing. Adding these solved the issue.
The interesting part here is that the suspect project has not been touched for years so the values had never have been set. A quick scan through our git logs confirms this. Ultimately I'm not sure what triggered this to become a problem but it is no longer.

MonoGame - Error 9009 & IgnoreMe.dll not found

i've just installed MonoGame and XNA and i'm having some issues from the jump, from googling it seems as though i need to add 'C:\Windows\System32' to my path environment variables, i've tried adding it here
but i'm still getting these errors
Error 1
The command "SETX MONOGAME_PLATFORM "PSM" > NUL" exited with code 9009. MyMonoGameContent
Error 2
Metadata file 'C:\Users\Benji\documents\visual studio 2013\Projects\myMonoGame\MyMonoGameContent\MyMonoGameContent\bin\PSM\IgnoreMe.dll' could not be found C:\Users\Benji\documents\visual studio 2013\Projects\myMonoGame\myMonoGame\CSC myMonoGame
This happens when i try to compile after referencing my content project
i'm following these http://rbwhitaker.wikidot.com/monogame-tutorials
no idea what's up, was that the wrong place to set the enviroment variable? i've tried looking for a user property sheet but can't find one in my project

I wouldn't expect that you would want to create content for the PSM (PlayStation Mobile). Check the targeted platform of the ContentBuilder project to ensure you are building for Windows.

Weird xCode linker error I've never seen before saying "Assertion failed"

Built this game through Unity, and managed to compile through xCode once before. Without any apparent changes, however, this error message turns up. I don't understand where to start looking for a fix, but maybe someone else have a clue? I've seen similar looking errors through searches, though the fixes seem arbitrary compared to mine.
Anyone able to shed some light? Thank you!!
0 0x1034de0e7 __assert_rtn + 144
1 0x10351350c archive::File<arm>::makeObjectFileForMember(archive::File<arm>::Entry const*) const + 1142
2 0x103512c9a archive::File<arm>::forEachAtom(ld::File::AtomHandler&) const + 416
3 0x10352a6a1 ld::tool::InputFiles::forEachInitialAtom(ld::File::AtomHandler&, ld::Internal&) + 465
4 0x10353490e ld::tool::Resolver::resolve() + 48
5 0x1034dec47 main + 679
A linker snapshot was created at:
/tmp/wingOstar-2014-09-26-171939.ld-snapshot
ld: Assertion failed: (memberIndex != 0), function makeObjectFileForMember, file /SourceCache/ld64/ld64-236.4/src/ld/parsers/archive_file.cpp, line 355.
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This seems like the kid of error the Xcode developers hope you never actually see...
The part of that message that is likely most useful for searching against will be the ld: Assertion failed: (memberIndex != 0), since that is the root of the error rather than supporting information.
I probably found the same few sources you did, but they indicated that this is caused by corruption in one of the resources Xcode is trying to link your program against, rather than something immediately caused by your own code. A file becoming corrupted by some external action would explain how this can happen despite no obvious changes in your program source.
So the obvious suggestion for fixing this would be to repair the corruption by making sure whatever is causing it gets recompiled. The first thing to do is to completely clean your project so that no older precompiled files are used and all of your own code is rebuilt. Since your error mentions a source cache, follow the recommendation here to wipe all caches, not just those cleared by the Product->Clean option.
The error message also gives a suggestion to use the -v flag to see what ld is actually doing, which may help you narrow down which object files could be corrupt (by showing you which ones are actually used). To add the flag, go to Build Settings in your project's settings, go down to Linking->Other linker flags, and add -v to those. Once you've rebuilt the project, look at the Build messages in the Report Navigator panel, and expand the linker messages for a full list of linked objects. If any of these options refer to libraries you provided, consider deleting and rebuilding them, before cleaning and rebuilding your project again.

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.