New F# 3.1 project templates break Mono

[Gustavo Guerra]

Hi,

When upgrading F# projects to VS2013, this:

<Reference Include="FSharp.Core, Version=4.3.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">

...

<Import Project="$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets" Condition=" Exists('$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets')" />

is changed to this:

<Reference Include="FSharp.Core, Version=$(TargetFSharpCoreVersion), Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">

...

<Choose>

  <When Condition="'$(VisualStudioVersion)' == '11.0'">

    <PropertyGroup>

      <FSharpTargetsPath>$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets</FSharpTargetsPath>

    </PropertyGroup>

  </When>

  <Otherwise>

    <PropertyGroup>

      <FSharpTargetsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.Targets</FSharpTargetsPath>

    </PropertyGroup>

  </Otherwise>

</Choose>

<Import Project="$(FSharpTargetsPath)" Condition="Exists('$(FSharpTargetsPath)')" />

This causes two problems:

-xBuild fails to replace $(FSharpTargetsPath) with $(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets (I'm guessing it doesn't support the <Choose> tag at all)

-Mono Develop/Xamarin Studio crashes when parsing "FSharp.Core, Version=$(TargetFSharpCoreVersion)", it's only expecting a version number and doesn't do any substitutions

I'm working on a pull request to fix the Mono Develop problem, but the xBuild problem will probably be much harder to fix. Does anyone know anyone that knows the xBuild source code and might be able to fix this?

Best Regards,

Gustavo Guerra

[Don Syme]

Hi Gustavo,

 

This does need to be fixed. I think you should add a Mono bugzilla bug about the xbuild issue.

 

Also email the Xamarin people about it too. If possible, help them find a fix.  Xbuild is obviously important to both Xamarin and Mono since they use it to build on OSX.

 

Cheers

Don

--
--
You received this message because you are subscribed to the Google
Groups "FSharp Open Source Community" group.
To post to this group, send email to fsharp-o...@googlegroups.com
To unsubscribe from this group, send email to
fsharp-opensou...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fsharp-opensource?hl=en
 
---
You received this message because you are subscribed to the Google Groups "FSharp Open Source Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fsharp-opensou...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Gustavo Guerra]

Hi Don,

I'll submit the bug to bugzilla, but according to my recent experience with the Alt-Enter ReSharper issue that had been submitted for years, it's probably best to contact someone directly. Is there anyone in particular at Xamarin I should contact?

Do you know if the <Choose> tag has been part of msbuild for a long time or if it was added just now in VS2012 update 3 and VS2013, to know if this a bug or just a new missing feature that hasn't been implemented yet?

Cheers,
Gustavo

---

From: Don Syme
Sent: 23/09/2013 02:39
To: fsharp-o...@googlegroups.com
Subject: RE: New F# 3.1 project templates break Mono

[Gustavo Guerra]

Bug filed here:

https://bugzilla.xamarin.com/show_bug.cgi?id=14922

Gustavo

On Monday, 23 September 2013 09:00:35 UTC+1, Gustavo Guerra wrote:

Hi Don,

I'll submit the bug to bugzilla, but according to my recent experience with the Alt-Enter ReSharper issue that had been submitted for years, it's probably best to contact someone directly. Is there anyone in particular at Xamarin I should contact?

Do you know if the <Choose> tag has been part of msbuild for a long time or if it was added just now in VS2012 update 3 and VS2013, to know if this a bug or just a new missing feature that hasn't been implemented yet?

Cheers,
Gustavo

---

From: Don Syme
Sent: 23/09/2013 02:39

To: fsharp-opensource@googlegroups.com

To post to this group, send email to fsharp-opensource@googlegroups.com

To unsubscribe from this group, send email to

fsharp-opensource+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/fsharp-opensource?hl=en
 
---
You received this message because you are subscribed to the Google Groups "FSharp Open Source Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fsharp-opensource+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
--
You received this message because you are subscribed to the Google
Groups "FSharp Open Source Community" group.

To post to this group, send email to fsharp-opensource@googlegroups.com

To unsubscribe from this group, send email to

fsharp-opensource+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/fsharp-opensource?hl=en
 
---
You received this message because you are subscribed to the Google Groups "FSharp Open Source Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fsharp-opensource+unsubscribe@googlegroups.com.

[Don Syme]

Hi all,

If you are looking for a way to contribute to F# cross-platform and mobile, then please do consider diving in and fixing this issue in Mono's xbuild.

I asked Miguel de Icaza and he said they don't have an xbuild specialist as such There are people who might pick it up. It would probably be better for the F#
community to submit a fix to mono xbuild ourselves.

Cheers,
Don

---

From: Gustavo Guerra
Sent: ‎23/‎09/‎2013 05:43
To: fsharp-o...@googlegroups.com
Subject: Re: New F# 3.1 project templates break Mono

To post to this group, send email to fsharp-o...@googlegroups.com

To unsubscribe from this group, send email to

fsharp-opensou...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/fsharp-opensource?hl=en
 
---
You received this message because you are subscribed to the Google Groups "FSharp Open Source Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fsharp-opensou...@googlegroups.com.

[Gustavo Guerra]

Hi,

I've started looking at this, but only got as far as building and debugging xBuild inside VS2012 and seeing the error manifest itself, but I won't have time the next couple of days to pursue this. If anyone wants to resume, get the code from https://github.com/ovatsus/mono/tree/xBuildFS31Problem and open the mcs/tools/xbuild/xbuild.sln solution. Passing a F# 3.1 .fsproj in the command line will cause the error on Import.cs:214. Looking in the debugger at project.PropertyGroups, I can see that the list of project.PropertyGroups is not including the PropertyGroup created inside the Choose element.

Cheers,

Gustavo

On Monday, 23 September 2013 12:27:06 UTC+1, Don Syme wrote:

Hi all,

If you are looking for a way to contribute to F# cross-platform and mobile, then please do consider diving in and fixing this issue in Mono's xbuild.

I asked Miguel de Icaza and he said they don't have an xbuild specialist as such There are people who might pick it up. It would probably be better for the F#
community to submit a fix to mono xbuild ourselves.

Cheers,
Don

---

From: Gustavo Guerra
Sent: ‎23/‎09/‎2013 05:43
To: fsharp-o...@googlegroups.com
Subject: Re: New F# 3.1 project templates break Mono

Bug filed here:

https://bugzilla.xamarin.com/show_bug.cgi?id=14922

Gustavo

On Monday, 23 September 2013 09:00:35 UTC+1, Gustavo Guerra wrote:

Hi Don,

I'll submit the bug to bugzilla, but according to my recent experience with the Alt-Enter ReSharper issue that had been submitted for years, it's probably best to contact someone directly. Is there anyone in particular at Xamarin I should contact?

Do you know if the <Choose> tag has been part of msbuild for a long time or if it was added just now in VS2012 update 3 and VS2013, to know if this a bug or just a new missing feature that hasn't been implemented yet?

Cheers,
Gustavo

---

From: Don Syme
Sent: 23/09/2013 02:39

To: fsharp-o...@googlegroups.com

[Gustavo Guerra]

Hi Don,

I have submitted two pull requests, but it still needs someone from Xamarin to look at them, integrate them, and eventually release the fixes

https://github.com/mono/mono/pull/767

https://github.com/mono/monodevelop/pull/407

Cheers,

Gustavo

---

To: fsharp-o...@googlegroups.com
From: don...@fastmail.fm

Subject: RE: New F# 3.1 project templates break Mono

Date: Mon, 23 Sep 2013 07:27:06 -0400

Hi all,

If you are looking for a way to contribute to F# cross-platform and mobile, then please do consider diving in and fixing this issue in Mono's xbuild.

I asked Miguel de Icaza and he said they don't have an xbuild specialist as such There are people who might pick it up. It would probably be better for the F#
community to submit a fix to mono xbuild ourselves.

Cheers,
Don

---

From: Gustavo Guerra
Sent: 23/09/2013 05:43

[Robin Neatherway]

Hi Gustavo,

Thanks a lot for working on this. It's really important to keep xbuild
parity. I'll try to test it out over the weekend if Xamarin don't
merge it first, hopefully a +1 will speed the process.

Robin

> To: fsharp-o...@googlegroups.com

[Gustavo Guerra]

I only tested it on Windows, so it will be good for someone to test it at least on a Mac. On windows it's using the .targets files on the default locations, I'm not sure how it resolves "$(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets" on Mac/Linux

To test create a F# project in VS2012 and then open it once in VS2013 to upgrade (don't create directly in VS2013 as that poses other problems that I haven't fully fixed yet)

Gustavo

[Robin Neatherway]

OK, I was planning to test on Linux. Is it possible install VS2013
alongside VS2012? I don't want to upgrade my dev machine permanently
yet.

[Gustavo Guerra]

You can install along side, but if you don't want to do it, you can see examples of what the upgrade does:

https://github.com/fsharp/FSharp.Data/commit/9ca8cbe4931b0aea3fe988776845a2e4fd7a3185

https://github.com/BlueMountainCapital/FSharp.DataFrame/commit/1c5ca05e4aad64c68a3dc150f9b715da9e50ba0c

Gustavo

[Robin Neatherway]

I tried compiling on Debian and receive:

Microsoft.Build.Utilities/ToolLocationHelper.cs(51,75): error CS0117:
`System.Environment.SpecialFolder' does not contain a definition for
`Windows'
./../../class/lib/net_2_0/mscorlib.dll (Location of the symbol related
to previous error)
Microsoft.Build.Utilities/ToolLocationHelper.cs(110,76): error CS0117:
`System.Environment.SpecialFolder' does not contain a definition for
`ProgramFilesX86'
./../../class/lib/net_2_0/mscorlib.dll (Location of the symbol related
to previous error)
Microsoft.Build.Utilities/ToolLocationHelper.cs(111,16): error CS0122:
`System.IO.Path.Combine(string, string, string, string)' is
inaccessible due to its protection level

I'm not sure what the Mono approach is to these special folders,
perhaps a #ifdef. The "protection level" error I don't understand.

[Gustavo Guerra]

Humm, I tried on a mac vm and  Environment.GetFolderPath (Environment.SpecialFolder.Windows) returns "", and I'm checking for empty string...

It seems you are compiling for 2.0, I compiled version 4.5, so probably the overload with params string[] didn't exist. I need to put that bit in a #ifdef, as it only applies to 4.5.

Cheers,

Gustavo

[Robin Neatherway]

I ran configure without any options, and got output:

Libraries:
.NET 2.0/3.5: yes
.NET 4.0: yes
.NET 4.5: yes

So I suppose I am compiling .NET 2.0 as well.

In fsharpi on this Debian install I get the same as you:

> Environment.GetFolderPath (Environment.SpecialFolder.Windows);;
val it : string = ""

[Gustavo Guerra]

I only compiled on windows with VS2012, but I had to hack it (https://github.com/ovatsus/mono/commit/7c8489bc3031cd6f6aaa072815012a239b918493)

Couldn't get autoconf and make to work properly neither in cygwin neither in the mac vm, but I am a *nix noob, and I gave up on the vm soon as it was painfully slow.

Can you try surrounding GetMSBuildInstallPath and var windowsPath = Environment.GetFolderPath (Environment.SpecialFolder.Windows);

with #if !NET_2_0 and see if it fixes the problem?

[Robin Neatherway]

OK, just trying that now. I used vagrant, which was very quick to get
a blank slate up and running.

[Robin Neatherway]

I also had to #if the new block you introduced, diff included at the
bottom. Then I received the following error:

Microsoft.Build.BuildEngine/Engine.cs(123,26): error CS0117:
`Microsoft.Build.Utilities.ToolLocationHelper' does not contain a
definition for `GetMSBuildInstallPath'



diff --git a/mcs/class/Microsoft.Build.Utilities/Microsoft.Build.Utilities/ToolLocationHel
index 730d882..ab9c402 100644
--- a/mcs/class/Microsoft.Build.Utilities/Microsoft.Build.Utilities/ToolLocationHelper.cs
+++ b/mcs/class/Microsoft.Build.Utilities/Microsoft.Build.Utilities/ToolLocationHelper.cs
@@ -48,7 +48,9 @@ namespace Microsoft.Build.Utilities
t2 = t1.Parent;

lib_mono_dir = t2.FullName;
+#if !NET_2_0
var windowsPath = Environment.GetFolderPath
(Environment.SpecialFo
+#endif
if (Environment.GetEnvironmentVariable
("TESTING_MONO") != null) {
mono_dir = new string [] {
Path.Combine (lib_mono_dir, "net_1_0"),
@@ -58,6 +60,7 @@ namespace Microsoft.Build.Utilities
Path.Combine (lib_mono_dir, "net_4_0"),
Path.Combine (lib_mono_dir, "net_4_5")
};
+#if !NET_2_0
} else if (!string.IsNullOrEmpty (windowsPath)
&& lib_mono_dir.Sta
//running in .NET, not Mono
mono_dir = new string [] {
@@ -68,6 +71,7 @@ namespace Microsoft.Build.Utilities
Path.Combine (lib_mono_dir,
"v4.0.30319"),
Path.Combine (lib_mono_dir,
"v4.0.30319")
};
+#endif
} else {
mono_dir = new string [] {
Path.Combine (lib_mono_dir, "1.0"),
@@ -104,12 +108,14 @@ namespace Microsoft.Build.Utilities
return mono_dir [(int)version];
}

+#if !NET_2_0
public static string GetMSBuildInstallPath (string version)
{
//see
http://msdn.microsoft.com/en-us/library/vstudio/bb397428(v=v
var programFiles = Environment.GetFolderPath
(Environment.SpecialF
return Path.Combine (programFiles, "MSBuild",
version, "bin");
}
+#endif

[MonoTODO]
public static string GetPathToDotNetFrameworkFile
(string fileName,

[Gustavo Guerra]

That's only called from a block surrounded with #if NET_4_5, so it seems the semantics of NET_2_0 is at least 2.0 and not strictly 2.0...

[Robin Neatherway]

> That's only called from a block surrounded with #if NET_4_5, so it seems the
> semantics of NET_2_0 is at least 2.0 and not strictly 2.0...

I think that is the semantics yes, but I'm not sure I follow why that
is a problem as this block is NET_4_5.

[Gustavo Guerra]

There's a #if !NET_2_0 around the definition of GetMSBuildInstallPath, which means it won't be defined neither for 2.0, 3.5, 4.0 or 4.5

[Robin Neatherway]

Sorry that is obvious now. Getting a bit late perhaps. So NET_3_5 might be what we want.

[Robin Neatherway]

OK I changed to #if NET_3_0 and it compiles fine now. Diff at the
bottom again. However, I created a standard console application
solution in VS2012, upgraded it with VS2013 and try to build it with
xbuild I receive an error. It builds the non-upgraded project without
problems.

vagrant@vagrant-debian-wheezy:~/testupgrade/testupgrade$ xbuild
testupgrade.fsproj
XBuild Engine Version 3.2.3.0
Mono, Version 3.2.3.0
Copyright (C) Marek Sieradzki 2005-2008, Novell 2008-2011.

Build started 10/01/2013 10:21:44.
__________________________________________________
Project "/home/vagrant/testupgrade/testupgrade/testupgrade.fsproj"
(default target(s)):
/home/vagrant/testupgrade/testupgrade/testupgrade.fsproj: error :
Target named 'Build' not found in the project.
Done building project
"/home/vagrant/testupgrade/testupgrade/testupgrade.fsproj".-- FAILED

Build FAILED.
Errors:

/home/vagrant/testupgrade/testupgrade/testupgrade.fsproj (default targets) ->

/home/vagrant/testupgrade/testupgrade/testupgrade.fsproj: error :
Target named 'Build' not found in the project.

0 Warning(s)
1 Error(s)

Time Elapsed 00:00:00.1099570





diff --git a/mcs/class/Microsoft.Build.Utilities/Microsoft.Build.Utilities/ToolLocationHelp
index 730d882..c763d59 100644

--- a/mcs/class/Microsoft.Build.Utilities/Microsoft.Build.Utilities/ToolLocationHelper.cs
+++ b/mcs/class/Microsoft.Build.Utilities/Microsoft.Build.Utilities/ToolLocationHelper.cs
@@ -48,7 +48,9 @@ namespace Microsoft.Build.Utilities
t2 = t1.Parent;

lib_mono_dir = t2.FullName;

+#if NET_3_0
var windowsPath = Environment.GetFolderPath
(Environment.SpecialFol

+#endif
if (Environment.GetEnvironmentVariable
("TESTING_MONO") != null) {
mono_dir = new string [] {
Path.Combine (lib_mono_dir, "net_1_0"),
@@ -58,6 +60,7 @@ namespace Microsoft.Build.Utilities
Path.Combine (lib_mono_dir, "net_4_0"),
Path.Combine (lib_mono_dir, "net_4_5")
};

+#if NET_3_0
} else if (!string.IsNullOrEmpty (windowsPath)
&& lib_mono_dir.Star

//running in .NET, not Mono
mono_dir = new string [] {
@@ -68,6 +71,7 @@ namespace Microsoft.Build.Utilities
Path.Combine (lib_mono_dir,
"v4.0.30319"),
Path.Combine (lib_mono_dir,
"v4.0.30319")
};
+#endif
} else {
mono_dir = new string [] {
Path.Combine (lib_mono_dir, "1.0"),
@@ -104,12 +108,14 @@ namespace Microsoft.Build.Utilities
return mono_dir [(int)version];
}

+#if NET_3_0

public static string GetMSBuildInstallPath (string version)
{
//see

http://msdn.microsoft.com/en-us/library/vstudio/bb397428(v=vs
var programFiles = Environment.GetFolderPath
(Environment.SpecialFo

return Path.Combine (programFiles, "MSBuild",
version, "bin");
}
+#endif

[MonoTODO]
public static string GetPathToDotNetFrameworkFile
(string fileName,

On Mon, Sep 30, 2013 at 11:27 PM, Robin Neatherway

[Gustavo Guerra]

That's weird. Can you run both the vs2012 project and the upgraded version with /verbosity:diag and do a diff to see if it's importing the wrong target files? The output should be the same.

Cheers,
Gustavo

---

From: Robin Neatherway
Sent: 01/10/2013 15:23

[Robin Neatherway]

The VS2012 project outputs the following:

home/vagrant/testupgrade/testupgrade/testupgrade - Copy.fsproj:
Importing project /usr/local/lib/mono/Microsoft
SDKs/F#/3.0/Framework/v4.0/Microsoft.FSharp.Targets from extension
path /usr/local/lib/mono/xbuild
/usr/local/lib/mono/Microsoft
SDKs/F#/3.0/Framework/v4.0/Microsoft.FSharp.Targets: Importing project
/usr/local/lib/mono/4.0/Microsoft.Common.targets

while the VS2013 project does not. So I suppose the FSharpTargetsPath
still isn't being replaced on my machine.

[Gustavo Guerra]

That's weird, because if $(FSharpTargetsPath) wasn't correctly replaced you would get a different error. You can reproduce that by commenting the groupingCollection.Evaluate (EvaluationType.Choose) line.
Unless there's something else that checks the import paths for known patterns when not running on widows, and the evaluation is too late, I have n idea what could be the problem...

---

From: Robin Neatherway
Sent: 01/10/2013 15:55

[Robin Neatherway]

Yes when I comment that line, I get 'testupgrade.fsproj: error :
/home/vagrant/testupgrade/testupgrade/testupgrade.fsproj: The required
attribute "Project" in Import is empty'

I'm pretty low on ideas too.

[Gustavo Guerra]

The message missing from the version that doesn't work is printed here: https://github.com/mono/mono/blob/0438680b67c83621f2025f51680b20f021d619f6/mcs/class/Microsoft.Build.Engine/Microsoft.Build.BuildEngine/Import.cs#L172

So has_extn_ref is probably not being set to true correctly.

has_extn_ref is set here (https://github.com/mono/mono/blob/0438680b67c83621f2025f51680b20f021d619f6/mcs/class/Microsoft.Build.Engine/Microsoft.Build.BuildEngine/Import.cs#L151):

bool has_extn_ref = project_attribute.IndexOf ("$(MSBuildExtensionsPath)") >= 0 ||
						project_attribute.IndexOf ("$(MSBuildExtensionsPath32)") >= 0 ||
						project_attribute.IndexOf ("$(MSBuildExtensionsPath64)") >= 0;

Can you put some prints here to check if  $(FSharpTargetsPath) is beign replaced with $(MSBuildExtensionsPath32)\..\Microsoft SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets, or if it's being replaced by something else?

On a different note, this two lines also sound suspicious. Shouldn't the F# ".Targets" also be replaced with ".targets"? But maybe this is unrelated

https://github.com/mono/mono/blob/0438680b67c83621f2025f51680b20f021d619f6/mcs/class/Microsoft.Build.Engine/Microsoft.Build.BuildEngine/Import.cs#L87

https://github.com/mono/mono/blob/0438680b67c83621f2025f51680b20f021d619f6/mcs/class/Microsoft.Build.Engine/Microsoft.Build.BuildEngine/Import.cs#L101

[Robin Neatherway]

> Can you put some prints here to check if $(FSharpTargetsPath) is beign
> replaced with $(MSBuildExtensionsPath32)\..\Microsoft
> SDKs\F#\3.0\Framework\v4.0\Microsoft.FSharp.Targets, or if it's being
> replaced by something else?

I'll have a go at this later to see what's going on, good idea.

> On a different note, this two lines also sound suspicious. Shouldn't the F#
> ".Targets" also be replaced with ".targets"? But maybe this is unrelated
> https://github.com/mono/mono/blob/0438680b67c83621f2025f51680b20f021d619f6/mcs/class/Microsoft.Build.Engine/Microsoft.Build.BuildEngine/Import.cs#L87
> https://github.com/mono/mono/blob/0438680b67c83621f2025f51680b20f021d619f6/mcs/class/Microsoft.Build.Engine/Microsoft.Build.BuildEngine/Import.cs#L101

The FSharp.Targets file on my machine has a capital 'T' unlike the C#
version. So I think this one is OK:

/usr/local/lib/mono/4.0/Microsoft.CSharp.targets
/usr/local/lib/mono/4.0/Microsoft.FSharp.Targets

[Gustavo Guerra]

I was able to reproduce this and found a fix. I'll update the pull request and then ask you to test again

Cheers,

Gustavo

[Gustavo Guerra]

Hi Robin,

I've added your patch and my fix to https://github.com/mono/mono/pull/767

Can you please retest?

Thanks,

Gustavo

[Robin Neatherway]

I've retested and added some debug printing. The results are:

ForEachExtensionPathTillFound
has_extn_ref: False
project_attribute: $(FSharpTargetsPath)
condition_attribute: Exists('$(FSharpTargetsPath)')
importPaths: /usr/local/lib/mono/xbuild/Microsoft/VisualStudio/v/FSharp/Microsoft.FSharp.Targets
extensionPaths: /usr/local/lib/mono/xbuild
has_extn_ref: True
extn_paths: /usr/local/lib/mono/xbuild

so I think FSharpTargetsPath is being replaced with
/usr/local/lib/mono/xbuild/Microsoft/VisualStudio/v/FSharp/Microsoft.FSharp.Targets,
which doesn't exist, although there are some files near there:

vagrant@vagrant-debian-wheezy:~/testupgrade/testupgrade$ ls -R
/usr/local/lib/mono/xbuild/Microsoft/VisualStudio/
/usr/local/lib/mono/xbuild/Microsoft/VisualStudio/:
v10.0 v11.0 v9.0

/usr/local/lib/mono/xbuild/Microsoft/VisualStudio/v10.0:
WebApplications

/usr/local/lib/mono/xbuild/Microsoft/VisualStudio/v10.0/WebApplications:
Microsoft.WebApplication.targets

/usr/local/lib/mono/xbuild/Microsoft/VisualStudio/v11.0:
WebApplications

/usr/local/lib/mono/xbuild/Microsoft/VisualStudio/v11.0/WebApplications:
Microsoft.WebApplication.targets

/usr/local/lib/mono/xbuild/Microsoft/VisualStudio/v9.0:
WebApplications

/usr/local/lib/mono/xbuild/Microsoft/VisualStudio/v9.0/WebApplications:
Microsoft.WebApplication.targets

[Gustavo Guerra]

I was hoping that would fix it, on Windows it's now giving me exactly the same output for the original and for the upgraded project. What's the output of xBuild now? Still the same?

Could you run it through the original VS2012 project and verify that it keeps working and see what's being printed for importPaths?

Can you also print projectPath and importingProject here: https://github.com/ovatsus/mono/blob/92eda1e2a6e5b4cbaecdfe1aa739b12bd328e9f1/mcs/class/Microsoft.Build.Engine/Microsoft.Build.BuildEngine/Project.cs#L1165

Can you also send me the output of ls -lR /usr/local/lib/mono/xbuild?

Cheers,

Gustavo

[Robin Neatherway]

We took this offline, but just to close the thread off, Gustavo has
fixed the Linux issues and updated his pull request accordingly.

[Robert Pickering]

Everything was working fine, then I forked mono so I could create a patch for another issue and after I re-installed I started getting this issue again. What sha of Gustravo's patch, so I check whether I have it in my tree?

Thanks,

Robert

[Robert Pickering]

Sorry, being an idiot, thought I was creating a new fork of mono, but turns out I already had one, so seems my tree is just a bit old.