Paket: VS2015 Update 1: MVC build fails with error MSB4064: The "Features" parameter is not supported by the "Csc" tas

[mlidbom]

There are a few twists to when you encounter this bug.
I eventually found that it occurs every time if:

• Packages are restored before build starts.
• The obj folder is missing
• The bin folder is missing

I've attached a zip with a repro solution.
Run build-fails.bat to see the build fail.
Run build-succeeds.bat to see the build succeed.

Edit: Seems the problem occurs with VS2015 Update 1. I'm afraid this likely means that every paket user with an MVC project will start to see their builds failing when they update.

Edit2: The exact error from the build log:

2>C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.CSharp.Core.targets(88,11): error MSB4064: The "Features" parameter is not supported by the "Csc" task. Verify the parameter exists on the task, and it is a settable public instance property.
2>C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.CSharp.Core.targets(67,5): error MSB4063: The "Csc" task could not be initialized with its input parameters. 

PaketBugRepro.zip

[inosik]

Strangely enough, both scripts work on my machine.

And actually, it shouldn't make any difference, since paket.targets already does paket restore before building.

There is somebody else having the same issue at StackOverflow and at the Roslyn repo (dotnet/roslyn#9538).

[mlidbom]

That is strange indeed.
I'm running in in the "Developer Command Prompt for VS2015"
Are you using the same version?

[inosik]

I don't have VS 2015 on this machine, only up to 2013.

So this is some MSBuild f**kery going on here, not an Paket issue.

[Stift]

I only can reproduce it when I explicitly use C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe

[mlidbom]

It may well be msbuild related, but before paket modified the csproj file it worked just fine.
I on the other hand don't have VS2013 on this machine. Will try to see if I can borrow one to see if I can verify that it works on VS2013.

[mlidbom]

Well it worked with "Developer Command Prompt for VS2012". So it does seem to be related to msbuild versions.

[Stift]

A little bit strange. The documentation of the Csc Task does not say anything about a Features Property (https://msdn.microsoft.com/en-us/library/s5c8athz%28v=vs.140%29.aspx)

[mlidbom]

And I just failed to recreate on another workstation that does have VS2015.
Even when I used the exact path to msbuild as Stift did.

That machine however did not have VS2015 Update 1 nor is it a Windows 10 machine like mine.
So Windows 10 and/or update 1 of VS2015 might be relevant.
Edit: I'm updating the other machine to update 1 to see if that breaks things.

@Stift: Do you have Update 1 and/or Windows 10?

[mlidbom]

Confirmed. It seems the problem occurs once you upgrade to VS2015 Update 1.
I'm afraid that may well mean that every MVC project using paket will stop working once the developers upgrade to VS2015 Update 1 .

[forki]

can I get a TLDR? What's the exact issue?

[Stift]

the props files don't get imported. in this case for microsoft.net.compilers

[Stift]

Oh. I see - They are imported but at the end of the file. VS puts them on top of the csproj. When I put manually the paket stuff on top, it works.

[forki]

It doesn't get imported? at all? or just too late? what do we need to change? XML looks correct to me.

[Stift]

Repro: Create a MVC project in VS 2015, convert it to paket, run C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe (VS 2015 Update 1)

[Stift]

xml looks okay, but position seems to play a role.

[mlidbom]

Ah, then this might be related to(possibly a duplicate) #1487

[mlidbom]

Repro: Create a MVC project in VS, convert it to paket, run C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe (VS 2015 Update 1)

@forki @Stift
That is excactly what I did to create the attached Zip. The Zip contains a git repo with the steps as separate commits along with the scripts to recreate the problem.

[forki]

ok looks like I have an idea how to fix this.

If we move the props up to right after the property groups (See https://gist.github.com/forki/479c1c8e355e69e165af#file-test-csproj-L44) then it builds for me.

[Stift]

i think it could also have to do with the package itself. I have to recheck but it seems newer versions of net.compilers package works fine

[Stift]

Ok.
When I do .paket\paket.exe update nuget Microsoft.net.Compilers version 1.1.1 & "c:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" /t:Rebuild then it works.
But .paket\paket.exe update nuget Microsoft.net.Compilers version 1.0.0 & "c:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" /t:Rebuild fails.

@mlidbom could you also reproduce this. Because then it seems to be a problem in the package.

[mlidbom]

@forki With the real problem solution (not the minimal repro havent tested with that) it only seems to work for me if I move the props to the very top of the csproj. Right below the imports Microsoft.TypeScript.Default.props and Microsoft.Common.props

Note that once you get it building you have to delete the obj and bin folder to recreate the problem again. It is easy to miss and believe that something works even though it does not.

[forki]

I did that. the file in the gist works fine for me. But it needs to be right after the propertygroups - otherwise it doesn't know which target framework was set

[mlidbom]

Ah, most likely me not doing the edits correctly then. I don't speak msbuild :)

[forki]

I don't speak msbuild :)

Nobody does.

My strategy:

[mlidbom]

:)

[inosik]

I bet if you remove the framework restriction from paket.dependencies and run paket install, it would work again.

If so, the solution would be, to import the .props file without the conditional __paket__... stuff, if the file is not framework-specific, regardless of the framework restriction.

[mlidbom]

I'm having real trouble trying to upgrade the compiler package in the problem solution.
Every time I run paket update it "automagically" downgrades all preversion packages to a non-preversion version. This breaks the compile completely

Is this a bug? If I explicitly ask for an upgrade of a singe package, should paket go ahead and downgrade each preversion packages automatically? Actually I find it odd to say the least that it would silently downgrade any package during any update operation....

[forki]

Yes that's true. But we need to find a solution that works with target
framework restrictions
On Mar 23, 2016 10:02, "Ilja Nosik" [email protected] wrote:

I bet if you remove the framework restriction from paket.dependencies and
run paket install, it would work again.

If so, the solution would be, to import the .props file without the
conditional paket... stuff, if the file is not framework-specific,
regardless of the framework restriction.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/fsprojects/Paket/issues/1537#issuecomment-200258644

[forki]

If I explicitly ask for an upgrade of a singe package, should paket go ahead and downgrade each preversion packages automatically

It tries to come up with a sound resolution. There are many things that have impact here. Please open another issue with the dependencies file, lock file and the command. I can the try to comment on the why.

[mlidbom]

Will do. Thank you.

[mlidbom]

@Stift @forki
For now I managed to update by adding => CURRENT_PRE_VERSION to each installed pre-version package in paket.dependencies(I don't really want to have to do that though...).
That way paket only updated the Microsoft.net.Compilers package and left the rest alone.

And yes. The problem does go away for me when using version 1.1.1 of Microsoft.net.Compilers. Thanks a lot for that tip @Stift, that will give us an instant workaround.

I would suggest though that a Paket-internal fix would still be a good idea. Who knows how many packages out there trigger the same problem? Or how many will run into this problem when converting old or new solutions like we did...

[forki]

Ok:

• we have a workaround for this issue - just use new package
• I will move the target specific props just below the propertygroups definitions. this will make it work for he referenced zip
• @mlidbom creates new issue with deps file, lock file and concrete update command and we will see if we have a resolver issue

[mlidbom]

@forki Added the new issue #1542

[forki]

@mlidbom can you please test with latest v3 alpha? I want to make sure it solves it before I release it in v2.

[mlidbom]

@forki That did indeed fix it. Thank you! :)

[forki]

What about others? Do you think this is good?
On Mar 24, 2016 12:06 PM, "Magnus Lidbom" [email protected] wrote:

@forki https://github.com/forki That did indeed fix it. Thank you! :)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/fsprojects/Paket/issues/1537#issuecomment-200788794

[mlidbom]

@forki I don't really understand the question. Could you clarify what you mean?

[forki]

I want to hear a "go" from other people that rely on props files.
On Mar 24, 2016 12:10 PM, "Magnus Lidbom" [email protected] wrote:

@forki https://github.com/forki I don't really understand the question.
Could you clarify what you mean?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/fsprojects/Paket/issues/1537#issuecomment-200790872

[Stift]

I just checked it and it looks okay.

Just FYI: It would be good enough to just have the import statement beneath the itemgroup and let the choose items next to each other. This works as well.

[forki]

thanks. Let's do it then.

[Stift]

And with that I just found another bug in the bootstrapper. Not a serious one. Will take care about this after Easter.

[cdrnet]

Since the property definitions depend on $(TargetFrameworkIdentifier) it seems to me in C# projects they need to be defined _after_ <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />. Otherwise none of the properties actually get defined and thus none of the targets being included. Unfortunately if I fix my build manually by moving the Microsoft.CSharp.targets up again it automatically moves it back down on each paket.exe install and breaking the build again.

[forki]

See https://github.com/fsprojects/Paket/blob/master/src/Paket.Core/ProjectFile.fs#L949

If you could send a PR which moves "k" right behind that node (if it exists) then this would be awesome.

[cdrnet]

So we would have the following indices? That would not break the MVC issue again?

Import-2
-> j
PropertyGroup-1
PropertyGroup-2
-> k (old)
Import-3
Import-4
-> k (new)
Other...

[forki]

That would not break the MVC issue again

don't think so. It's still very "high" in the xml.

[cdrnet]

I've just realized you actually proposed to move it right behind Microsoft.CSharp.targets _in general (if it exists)_, not only in cases it had been moved up as in my workaround.

Should it look specifically for <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />?

[forki]

yes I think that would be better

[forki]

actually I think that would indeed fix all the current issues. (until we find the next one)

[forki]

see https://github.com/fsprojects/Paket/pull/1564

[forki]

please try with 2.57.1

[forki]

@mlidbom does it still work for you?

[mlidbom]

I'm afraid not (Actually I don't think it ever did. I must have screwed up testing it somehow. Sorry.).
From my experimenting it seems as though we have a catch 22 style situation here:

• The two prop file imports have to happen before the csharp targets import. If they are imported after we get the error: The "Features" parameter is not supported by the "Csc" task.
• The two prop files imports cannot happen before the csharp targets import since $(TargetFrameworkIdentifier) is not defined before we import the csharp targets and $(TargetFrameworkIdentifier) is one of the conditions that we use to define if we should import the prop files.

I'm attaching a zip with a git repository that attempts to illustrate this with different branches and commits.

PaketBugRepro.zip

[forki]

but it still works with latest version of said package?

[mlidbom]

I was about to say no until I checked and it turns out that there are two new stable versions.

Version 1.1.1 no longer works. I get error MSB4064: The "PublicSign" parameter is not supported by the "Csc" task. Likely related to me having updated to update 2 of VS2015.

But luckily it does work with the 1.2.0 and 1.2.1 versions of the package that were both released March 31.

[forki]

so latest version of the package works with latest version of paket?

[mlidbom]

Yes.

[kjellski]

Hi there,
I'm currently getting the same error. I'm using Paket 2.63.3.0

I've recently installed the VS15 Pre, might that be something to take into consideration?

If I create a new Asp.Net Web application with MVC4, I can build it fine. Then I've just opened up paket and tried a "convert-from-nuget" and afterwards it fails with this error.

This is the paket.dependencies file created:

paket.dependencies.txt

Can I provide any other information to guide you?

[forki]

Can you please create a sample with the broken csproj and a manually fixed version?

[kjellski]

@forki I've got no clue about how to fix this, but here is a link to the example: https://github.com/kjellski/paket-conver-from-nuget-example

[forki]

Did you try to update like it was described above?

[kjellski]

@forki I'm really sorry, I must have missed the instructions... should I try to reproduce with version 3.0.0-beta028 of paket or how can I try to fix this by myself? I don't understand how you rearranged the xml to be honest... :/

[forki]

I meant did you try to use the latest packages. There was a bug in on of
the older versions that made only work with nuget. But AFAIK the latest
fixes made it work with paket.
On May 4, 2016 1:06 PM, "Kjellski" [email protected] wrote:

@forki https://github.com/forki I'm really sorry, I must have missed
the instructions... should I try to reproduce with version 3.0.0-beta028 of
paket or how can I try to fix this by myself? I don't understand how you
rearranged the xml to be honest... :/

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/fsprojects/Paket/issues/1537#issuecomment-216829836

[kjellski]

Ah, no, I've just created a brand new project from VS2015 and let it do its thing, then I've made sure to build and run it once to confirm it's working. After that, I've used "paket convert-from-nuget" and let it do its thing. Afterwards it was broken. I've not updated anything.

[forki]

Yes. I understand. But as described above that's not going to work with our
choose nodes. Paket only works with the fixed nuget packages. I know that
the older ones work with nuget, but that's because of different structure
in the csproj.

I know this sounds stupid, but I think there is nothing we can do here. You
need to update to newer versions of the packages and then I hope it's going
to work again.
On May 4, 2016 1:10 PM, "Kjellski" [email protected] wrote:

Ah, no, I've just created a brand new project from VS2015 and let it do
its thing, then I've made sure to build and run it once to confirm it's
working. After that, I've used "paket convert-from-nuget" and let it do its
thing. Afterwards it was broken. I've not updated anything.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/fsprojects/Paket/issues/1537#issuecomment-216830524