-
Notifications
You must be signed in to change notification settings - Fork 17
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
Add support for VS2015 C# 6.0 projects #12
Comments
What should it be using? I imagine the workaround is to figure out what it should be pointing to - I believe right now it looks at the .NET Framework based on the framework selected and uses the Msbuild from that. |
Yes, the MSBuild task from Nant.Contrib that is used uses the .NET Framework version to determine which MSBuild executable to use. It searches the following locations
This was changed for VS 2013 to no longer be part of the framework but a separate installation alongside VS. This article gives more details on msbuild as a part of visual studio] and where to find the MSBuild executable. Unfortunately Nant.Contrib seems to no longer be maintained so it's unlikely to be fixed there. The extra paths that need to be searched (for VS 2013 & VS 2015 support) are
Using the highest version available would be perfect for my requirements but I guess this wouldn't work for everyone so there'd need to be some way of choosing which version to use. What do you think? |
Do you want to take a look at what just got added and see if that fixes things for you? |
Or rather, what .net framework should it be using? |
Hi Rob, With the latest build of UppercuT the build fails because the incorrect version of msbuild is invoked:
I'm not sure the issue can be fixed while still using nant without either using exec to call the correct msbuild manually or alternatively fixing Nant.Contrib.Tasks (this project seems dead?). |
This commit adds support for manually specifying the MSBuild path (https://github.com/coxp/uppercut/commit/07977aa5187320ba3dc2c87fd0a17535062c0ded). To specify the latest MSBuild to allow C# 6.0 syntax add the following lines to your .uppercut file
If you would like to still use the old msbuild task from nant.contrib but are running on a machine that only has Visual Studio 2015 installed, then add the following line to your .uppercut file. This will not allow you to use C# 6.0 features but will allow you to build projects (previously the build would fail because of missing targets in the Visual Studio directory).
|
Does that work? :) Update: Nevermind, there was additional work necessary to get it to build. |
We've started to add net-45 to the mix, perhaps explore the option of adding to the nant.exe.config for pointing to a particularly new location? |
The issue with extending the nant.exe.config is that MSBuild is no longer tied to the .net framework like it used to be. I think that it why no one has updated the nant.contrib task, as the task doesn't contain any code for locating the executable, it just uses a special attribute to say that the executable is in the current .net framework directory. The changes seem to work for me and I can use C# 6.0 features now :). There are a few issues with the latest bits that I think just haven't been used by anyone yet. The current outstanding issue for the project that I'm working on is that the environment files from the deployment directory are expanded in the current deployment directory (it used to use a temporary directory). |
Hmm. Okay. Well I was under the impression that you could add a build type in the same way mono (not a .net framework) has done and it would work. You could call it msbuild-14 |
I guess that would work. Would you then need a combination of framework and msbuild (e.g. msbuild-14-net46, msbuild12-net45)? |
That's a good question. I think you are in the best place to be able to answer that right now. |
I'm having trouble migrating a project to C# 6.0 as the Nant task used to build the solution uses the incorrect MSBuild executable.
Is there a workaround for this?
The text was updated successfully, but these errors were encountered: