-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revert the change to update default tools version #455
Conversation
Setting this to 12.0 on mono no longer causes an exception which means that 12.0 is always used. The problem with this is that any iOS projects fail completely on the line `project.Load(fsprojFile)`. So setting this to 4.0 on mono seems the safest thing to do.
From Travis it looks like this breaks on Mono 4.0.x |
ha, well currently its broken on mono 4.2 |
RE |
On my system I get all 5 references (Mono JIT compiler version 4.0.4). I think it's worth turning the logging on for your system and rerun the tests to see what the problem is. |
No errors:
|
I get the same failing test with and without the patch.
|
@rneatherway Would the project reference dll normally be in Because thats combing back empty. |
Yes, that's what I expect. |
Hmm, well Im stumped, no idea |
@rneatherway Do you have the log that produced the correct result so we can compare it to the one above? |
Sure I'll run it tomorrow. |
|
This mono commit looks to have broken FCS: mono/mono@76c6a08#diff-59afd196a55d61d5d1eaaef7bd49d1e5 |
Im closing this as I no longer want this merged, but the issue still exists with mono, Im not sure whether a patch is required to mono or here yet. |
@7sharp9 I'm surprised that is what causes it because I do set |
If I revert that change, all the test pass. |
OK, that's certain then! I took another look and I guess various things are ending up in |
I'm pretty sure problem appears here where XBuild/Mono in case of solution not set bails out and doesn't set anything: But MSBuild/.Net does some magic: FYI, we will revert this change soon, since it's causing too much problems and revisit it for next release... |
Actually I'll reopen this, with the mono changes reverted we are still in the same position. Project that have no tools version specified are implicitly initialised with 12.0. For projects with no tools version this can result in errors such as iOS applications, where the loading of the initial project simply fails:
|
I believe the tests fail because the msbuild calls need to be made with assembly redirects, otherwise there will always be version mismatches with 4.0/12.0. In XS we call the API from a separate process with assembly redirects in place to handle this. |
@7sharp9 I have an almost-completed PR for out-of-process project cracking. Hopefully that will fix this issue. |
Yeah its fiddly in process, this previously worked because it threw an exception assigning 12.0 to the default version, thus it always assigned 4.0. With the latest mono it no longer throws and the build engine fails instead when the project is loaded. |
Closing as this was address by @rneatherway's PR 👍 |
Setting this to 12.0 on mono no longer causes an exception which means
that 12.0 is always used.
The problem with this is that any iOS projects fail completely on the line
project.Load(fsprojFile)
. Sosetting this to 4.0 on mono seems the safest thing to do.