VS2012 projects don't xbuild on Linux

[funnelweb]

VS2012 project use Exists('....Microsoft.FSharp.Targets') but xbuild 'Exists' is currently case-sensitive on Linux and the targets file is installed as Microsoft.FSharp.targets.

xbuild should be fixed to be case-insensitive since the aim is compat with msbuild. The fix would take some time to propagate, and in the meantime we should go back to installing as Microsoft.FSharp.Targets

[DanielFabian]

You need to call the following in your bash before running xbuild, and it works:

export MONO_IOMAP=all

this fixes / vs \ in paths and makes mono be case-insensitive but case-preserving for paths. The mono guys already fixed this issue globally, so I would suggest to not fix it in the application.

[funnelweb]

OK, that seems reasonable. We should verify the problem goes away with a latest build of Mono.

[knocte]

What do you mean with "mono guys already fixed this globally"?

Now that I think about this, I recall that at some point xbuild has received some commits in regards to MONO_IOMAP behaviour.

[DanielFabian]

i mean, that mono has the MONO_IOMAP environment variable for exactly that use-case. So if you set it with an export in your build.sh, it should just work. (That's btw, what I was doing when doing mono-compatbility for fsharpx)

[funnelweb]

So the user would still have to manually set MONO_IOMAP? That's not enough - we need to have VS2012 projects build on linux without change and without setting environment variables.

In this case we should go back to installing as Microsoft.FSharp.Targets.

[funnelweb]

The fix is not hard see funnelweb@9c538e5

(It is frustrating to see we have a CRLF <--> LF change in FSharpSource.targets in that commit - I have no idea why git decided to CRLF --> LF on all of FSharpSource.targets - the current .getattributes is 'auto' and seems the right setting to use, so maybe this is just normalizing it back to something sensible.)

[DanielFabian]

The point it, that you usually need to set MONO_IOMAP anyway if you work with paths. And you won't be able to guarantee that VS2012 projects build without the setting. If nothing else, then you don't have control over FAKE scripts and they run into exactly the same problem.

It's really a matter of setting the variable before running xbuild (or FAKE for that matter)

[funnelweb]

I see, though it is not good enough. Simple VS2012 projects must build out of the box on linux using 'xbuild', and they seem to apart from the Exists(...targets) v. Exists(...Targets ) problem. Other file operations in xbuild are case insensitive without needing environment variables

We can't expect user of MonoDevelop to set environment variables etc.The baseline we have to reach is that 'xbuild' works on VS2012 projects without the environment variable.

p.s. the behavior of FAKE is not the question here because FAKE is not part of fsharp/fsharp - if FAKE needs the environment variable then that's up to @forki et al to document over in fsharp/FAKE.

[DanielFabian]

Fair enough, if it works that way, that's even better.

[funnelweb]

Can someone give advice on what the crlf/text .gitattributes setting for this project should be?

• When we use this a one line change to FSharpSource.targets (but not other files) becomes a full file change.

   text=auto 

• When we remove this, then a one line change stays a one line change.
• The previous setting was this one, I'm not sure what difference this makes

   # Disable LF normalization for all files
   * -text

It could be we should stick with text=auto and that FSharpSource.targets was just in some funny state due to a previous botched normalization.

[funnelweb]

Now that I look at it there has been previous CRLF trauma with this file. I think we should just stick to

    text=auto 

now and pay the cost of another change. Presumably github will now look after things automatically from here on.

Some previous checkins giving wholesale CRLF changes in that file have been

debb8de#src/FSharpSource.targets

7445bcf#src/FSharpSource.targets