locked
Build failed. Could not find type 'System.Globalization.SortVersion' RRS feed

  • Question

  • User2953 posted

    I recently updated my development environment to 4.2.4 Build 35 and I can no longer build our solution. Xamarin Studio fails with an error that states:

    Build failed. Could not find type 'System.Globalization.SortVersion'.
    

    This happens when it tries to build or clean the very first project in the dependency tree in the Solution.

    I upgraded to 4.2.5 Build 0 this morning and the problem is still there. Tried on multiple machines with multiple OSes (Win7 and Win8) and the failure continues, so it's not an environment problem.

    It's definitely a problem in Studio, as the build server, which uses gmcs through Jenkins continues to build the solution without any problem.

    Rolling back to 4.2.3 Build 60 eliminates the error.

    Wednesday, May 7, 2014 2:00 PM

All replies

  • User28 posted

    Are you trying to build on Windows with Mono as the runtime?

    Wednesday, May 7, 2014 3:22 PM
  • User2953 posted

    Yes, that is correct. Building on Windows, using Mono as the runtime.

    Wednesday, May 7, 2014 4:43 PM
  • User28 posted

    This is due to a change in the .NET binary serialization compatibility in .NET 4.5.1, which affects the remoting channel XS uses to connect to the builder process. It should be fixed in the next version of Mono.

    That said, I'd recommend building using .NET for building on Windows, since we don't really test the Mono build engine on Windows. If you just want to check Mono compatibility, you can use Run->Run with-> Mono to run on Mono, even when building with .NET.

    Friday, May 9, 2014 10:25 PM
  • User47965 posted

    Workaround that I use is to open project settings and uncheck Build->General->Use MSBuild build engine.

    Sunday, May 11, 2014 5:59 AM
  • User18246 posted

    I solved the problem in the past with "uncheck Build->General->Use MSBuild build engine.", however in the latest version (5.2) that option is not available.

    Is there a new fix for this very old problem?

    Tuesday, August 5, 2014 6:53 PM
  • User68011 posted

    Michael, in the 5.2. version You can find 'Use MSBuild engine' option at Project -> YourProjectName Options -> General

    Friday, August 8, 2014 12:39 PM
  • User68098 posted

    Hi Vlad, I can't find the MSBuild option in Xamarin 5.2 (build 386). Is there any simpler work around? Thanks!

    Saturday, August 9, 2014 3:22 AM
  • User68011 posted

    Tyrone, I`ve mark the 'project options' menu item in Xamarin 5.2. on the picture (attached to the next post). Then select Build -> General and uncheck 'Use MSBuild engine' option .

    Tuesday, August 12, 2014 7:26 AM
  • User68011 posted

    Image for previos post:

    Tuesday, August 12, 2014 7:39 AM
  • User18246 posted

    vladru,

    Here is what my Build/General window looks like (5.2, 5.2.1):

    There is no way to uncheck 'Use MSBuild engine' option... it no longer exists!

    Regards, MikeN

    Tuesday, August 12, 2014 6:56 PM
  • User68011 posted

    Michael, My windows are attached. I use Mono3.3.0. May be You have old versions of Mono ?

    Tuesday, August 12, 2014 8:04 PM
  • User18246 posted

    vladru,

    I am using Mono 2.10.9 as the Active Runtime. Since I also have 3.3.0 installed, I tried that as well. No change.

    I will fall back to XS 5.1.2, the last version that works for me.

    Thank you for your assistance, but this seems like a long-time problem for XS... perhaps it will eventually be fixed.

    MikeN

    Tuesday, August 12, 2014 8:21 PM
  • User28 posted

    Is there any particular reason why you need to use the Mono runtime to compile your project?

    Wednesday, August 13, 2014 3:04 AM
  • User18246 posted

    Michael,

    Why would I want to build against a different runtime than I plan to execute against? It would require a lot of faith to believe that building against a different runtime would flawlessly execute against a different runtime (especially a runtime with a lower version number).

    That way I can test in Windows, and confirm on Linux (the ultimate execution environment).

    There are many things that work fine with .Net runtimes that fail under mono/.net runtimes... which is a different issue that getting the build to work... but it contributes to my skepticism about building against a different set of runtimes.

    MikeN

    Wednesday, August 13, 2014 12:18 PM
  • User28 posted

    Building and execution are very different. When you build, you use a toolchain - some MSBuild implementation, which will use compilers and other tools - to build your source code against compile-time assemblies, creating an assembly. At runtime, a runtime loads your assembly and resolves its references against runtime assemblies.

    The assemblies used at compile-time and at runtime don't have to be the same, they just have to have the same API. In fact, they aren't the same even on .NET. And differences in the implementation of the compile-time assemblies won't affect what happens at runtime. You may catch superficial API differences, but not implementation differences, and that's where real issues usually lie.

    If you're a desktop/server framework such as .NET 4.5 then there are essentially three areas of compatibility:

    1. Toolchain - the .NET/Mono toolchains produce assemblies that are compatible
    2. API - Mono has the same APIs as .NET
    3. Runtime - the Mono APIs are implemented and behave the same way as .NET

    Right now on Windows the .NET toolchain is better tested and tuned than Mono's, and produces assemblies that work perfectly well on Mono, so there's not much reason to support the Mono toolchain on Windows. I'd love to support it but it offers very little concrete benefit and makes a lot of things very complicated. It's likely we'll remove Xamarin Studio's support for the Mono toolchain on Windows in the future.

    Xamarin's products use the .NET toolchain for building Xamarin.Android and Xamarin.iOS apps on Windows - they're compiled with .NET's MSBuild, using .NET's C# compiler. However, they're built against Mono reference assemblies. And at runtime they run on Mono.

    As long as you're not using the big unsupported areas like WPF, or advanced MSBuild customization, then almost all of the issues you run into will be runtime. And you're worried about API differences you can set MSBuild properties to have it build against the Mono framework assemblies, while still using the .NET toolchain.

    Wednesday, August 20, 2014 4:30 AM
  • User18246 posted

    Michael,

    Thank you for the thorough explanation!

    Wednesday, September 3, 2014 8:10 PM
  • User72830 posted

    I created a project named App.Windows in VS2013, the . causes the issue. I created a new project named AppWindows (without the .), builds without errors.

    Tuesday, September 9, 2014 3:54 AM