8

When trying to build in MonoDevelop with Mono for Android I get this error. According to the debug it is not located in my code so im left clueless. Any idea?

Error MSB4185: The function "CurrentUICulture" on type "System.Globalization.CultureInfo" has not been enabled for execution. (MSB4185)

Magnus Johansson
  • 28,010
  • 19
  • 106
  • 164
user1439648
  • 81
  • 1
  • 2

3 Answers3

6

I own MSBuild (and this code). It's an error originating in the file microsoft.csharp.targets, as the error message probably says. In there is a property function:

$([System.Globalization.CultureInfo]::CurrentUICulture.Name)

What the error means is that it thinks that this function isn't in MSBuild's "safe list". These are selected functions that have no side effects. (If you want to use any function, you must have an environment variable MSBUILDENABLEALLPROPERTYFUNCTIONS=1).

I really don't know why this would appear unless somehow you're using the 4.5 microsoft.csharp.targets with the 4.0 microsoft.build.dll (which didn't have it in the safe list). I haven't received reports of this except in connection with Monodevelop.

Excuse my naivety, but I'm assuming Monodevelop is using the Microsoft .NET Framework with the Microsoft MSBuild and not a reimplementation of that.

Dan

dan
  • 531
  • 4
  • 2
  • Uninstalling 4.5 would "fix" this because microsoft.csharp.targets would roll back to the 4.0 version. Of course, you don't have 4.5 any more then. – dan Jun 18 '12 at 16:27
  • It also occurs to me that you can trivially verify that microsoft.csharp.targets and microsoft.build.dll are in sync by building a C# project with msbuild.exe. This assumes that Monodevelop isn't loading different copies from some custom location, of course. – dan Jun 18 '12 at 16:27
  • 2
    Ugh, I figured out the problem. Apparently you're using the old OM (from microsoft.build.engine.dll) rather than the 4.0+ OM (from microsoft.build.dll). We reshipped the old OM for compat, just in case anyone (like MonoDevelop apparently) was using it. msbuild.exe 4.0+ and VS2010+ of course use the new OM, so the old one was relatively untested. And iff you use the old OM, on 4.0 or 4.5 project, with 4.5 .NET framework installed, AND the property BuildingInVisualStudio=true (which I'm guessing Monodevelop sets) you get this error. – dan Jun 18 '12 at 17:00
  • We're in escrow for 4.5 so we'll consider our options. Meanwhile the "best" way to fix it would be to move to the new OM. That's not one line of code, but it's not difficult per se either. – dan Jun 18 '12 at 17:00
  • thanks a lot for the information. We'll try to use the new OM, it shouldn't be too hard. – Lluis Sanchez Jun 18 '12 at 17:17
  • OK. I'm going to tell our compat board that this /isn't/ blocking Mono Develop then - unless you clarify otherwise. Let's continue this conversation by mail -- my email is msbuild@microsoft.com. – dan Jun 18 '12 at 19:58
  • Quick summary on why we're using the old hosting API for anyone who's interested: we use the "correct" version of MSBuild for the version of the projects that we're building, remoted onto a builder exe running on the target runtime. For example we use MSBuild 2.0 when building VS2005 (ToolVersion="2.0") projects. This means that we have to use 2.0 hosting API. Also Mono's MSBuild implementation doesn't support the 4.0 hosting APIs yet. – Mikayla Hutchinson Jun 18 '12 at 20:30
  • But this hosting model means we have to have a different variant of the exe for each ToolsVersion, built against the appropriate framework version. So, we should be able to add a new builder exe that uses the 4.0 hosting API, and use it when targeting MS.NET 4.0+. – Mikayla Hutchinson Jun 18 '12 at 20:31
  • (Can someone start an email thread at msbuild@microsoft.com, since this probably isn't an appropriate use of stack overflow :) ) (1) I'd love to get confirmation that if you set MSBUILDENABLEALLPROPERTYFUNCTIONS=1 it works OK (2) MSBuild vN is capable of building ToolsVersion=X where X is any number up to N. So you should be able to simply use the newest MSBuild available. It's true Visual Studio forces them to match but it shouldn't be needed. – dan Jun 19 '12 at 16:48
  • I'm happy to say that we submitted a fix for this. It will be in the final release. Thanks for reporting it! – dan Jun 22 '12 at 20:55
5

The working solution for me is this:

Open a CMD and run this command on it: setx MSBUILDENABLEALLPROPERTYFUNCTIONS 1

Another solution I think is available is installing Mono Runtime and set it as your default CLR runtime from Tools -> Options -> .NET Runtimes.

Ebrahim Byagowi
  • 10,338
  • 4
  • 70
  • 81
1

After uninstalling .NET Framework 4.5 RC from my Windows 7 machine, this error disappeared. Of course make sure you have valid .NET runtime after you uninstall 4.5.

Dominique
  • 817
  • 1
  • 5
  • 10