For my master thesis I'm building a Visual Studio plugin that should perform some code-analysis of the current opened solution.
In order to do that I've decided to try to use Roslyn, using the corresponding nuget package.
Everything works fine (SyntaxTree for navigating the code,...) until I've tried to use MSBuildWorkspace.Create().
This last call causes the following exception:
Could not load file or assembly 'Microsoft.Build, Version=14.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its
dependencies. The system cannot find the file
specified.":"Microsoft.Build, Version=14.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a
I found this two posts:
Creating new Microsoft.CodeAnalysis.CustomWorkspace - got ReflectionTypeLoadException
MSBuildWorkspace.Create() throws exception
from which I understand that I need the MSBuild Tools for Visual Studio 14, which is in the related iso.
I do not want to install the full Visual Studio 14, this also because the plugin that I'm writing should run under Visual Studio 2013. From the two post it seems that I can install only this part of VS 14.
My question actually is: if I install MSBuild Tools for Visual Studio 14 what will happen with all other Visual Studio projects that I'm currently working on?
At the moment they use the MSBuild tool of Visual Studio 2013. It's possible to still use that?
Update
What I'm acctually trying to get is to find if a given method has references inside the project. The idea was to proceed as in this post.
When you say you're building a plugin for Visual Studio, if all you care about is getting the workspace for the currently open solution (i.e. the code the user is editing), you shouldn't use MSBuildWorkspace, really ever. That's a type for loading things outside of Visual Studio. What you can do if you're in the product is MEF [Import] Microsoft.VisualStudio.LanguageServices.VisualStudioWorkspace. That gives you live access to what the user has open, and avoids running MSBuild entirely.
Note you're still going to have to be careful about your choice of reference assemblies you build against: if you use the latest NuGet packages that won't work since those will differ in version (and also APIs -- we changed a bunch of stuff) than what was in the last Visual Studio 2013 preview.
The issue is that (unfortunately) the assemblies in the public Roslyn nuget packages have been compiled with a newer version of MSBuild than what you want.
However, it's pretty simple to fix so that it works on MSBuild 4.0 (VS2012+). I've provided them with a PR with the fix (at https://roslyn.codeplex.com/workitem/405), but also published a nuget package called DesktopAnalysis that contains all the assemblies for doing C# code analysis, that work on VS2012+ (MSBuild 4.0+): https://www.nuget.org/packages/DesktopAnalysis
Just do an install-package DesktopAnalysis -pre instead and you're done. The assemblies are the same, the code is the same, etc.
I'm using this to provide a code migration extension that works from VS2013 all the way to VS2015 Preview.
You could fork the Roslyn codebase, and compile with MSBUILD12 defined, which should still work, though we don't really test this much.
This is entirely possible, but not at all easy.
You need to make sure that you only ever load the version of the Roslyn assemblies that is in the VS version you're targeting, by removing those assemblies from your VSIX and handling AssemblyResolve to make sure you get the right ones.
You can see my code that does exactly that here, and you can read more about this technique in my blog post
Note that if you need to [Export] any interfaces defined in Roslyn assemblies, this will not work at all, since MEF will try to load them before you add your handler. (unless you add a module initializer by hand in ildasm)
The harder part is that you need to limit yourself to the intersection of the APIs in every Roslyn version you want to support.
Related
I was going through the latest features introduced in C# 6.0 and just followed an example of auto property initializer,
class NewSample
{
public Guid Id { get; } = Guid.NewGuid();
}
but my IDE did not recognize the syntax.
I am wondering how I could enable C# 6.0 in Visual Studio 2013. The Target framework I am using is 4.5.1.
Under VS2013 you can install the new compilers into the project as a nuget package. That way you don't need VS2015 or an updated build server.
https://www.nuget.org/packages/Microsoft.Net.Compilers/
Install-Package Microsoft.Net.Compilers
The package allows you to use/build C# 6.0 code/syntax. Because VS2013 doesn't natively recognize the new C# 6.0 syntax, it will show errors in the code editor window although it will build fine.
Using Resharper, you'll get squiggly lines on C# 6 features, but the bulb gives you the option to 'Enable C# 6.0 support for this project' (setting saved to .DotSettings).
As mentioned by #stimpy77: for support in MVC Razor views you'll need an extra package (for those that don't read the comments)
Install-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
If you want full C# 6.0 support, you'll need to install VS2015.
Information for obsoleted prerelease software:
According to this it's just a install and go for Visual Studio 2013:
In fact, installing the C# 6.0 compiler from this release involves little more than installing a Visual Studio 2013 extension, which in turn updates the MSBuild target files.
So just get the files from https://github.com/dotnet/roslyn and you are ready to go.
You do have to know it is an outdated version of the specs implemented there, since they no longer update the package for Visual Studio 2013:
You can also try April's End User Preview, which installs on top of Visual Studio 2013.
(note: this VS 2013 preview is quite out of date, and is no longer updated)
So if you do want to use the latest version, you have to download the Visual Studio 2015.
A lot of the answers here were written prior to Roslyn (the open-source .NET C# and VB compilers) moving to .NET 4.6. So they won't help you if your project targets, say, 4.5.2 as mine did (inherited and can't be changed).
But you can grab a previous version of Roslyn from https://www.nuget.org/packages/Microsoft.Net.Compilers and install that instead of the latest version. I used 1.3.2. (I tried 2.0.1 - which appears to be the last version that runs on .NET 4.5 - but I couldn't get it to compile*.) Run this from the Package Manager console in VS 2013:
PM> Install-Package Microsoft.Net.Compilers -Version 1.3.2
Then restart Visual Studio. I had a couple of problems initially; you need to set the C# version back to default (C#6.0 doesn't appear in the version list but seems to have been made the default), then clean, save, restart VS and recompile.
Interestingly, I didn't have any IntelliSense errors due to the C#6.0 features used in the code (which were the reason for wanting C#6.0 in the first place).
* version 2.0.1 threw error The "Microsoft.CodeAnalysis.BuildTasks.Csc task could not be loaded from the assembly Microsoft.Build.Tasks.CodeAnalysis.dll. Could not load file or assembly 'Microsoft.Build.Utilities.Core, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
UPDATE One thing I've noticed since posting this answer is that if you change any code during debug ("Edit and Continue"), you'll like find that your C#6.0 code will suddenly show as errors in what seems to revert to a pre-C#6.0 environment. This requires a restart of your debug session. VERY annoying especially for web applications.
It worth mentioning that the build time will be increased for VS 2015 users after:
Install-Package Microsoft.Net.Compilers
Those who are using VS 2015 and have to keep this package in their projects can fix increased build time.
Edit file packages\Microsoft.Net.Compilers.1.2.2\build\Microsoft.Net.Compilers.props and clean it up. The file should look like:
<Project DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>
Doing so forces a project to be built as it was before adding Microsoft.Net.Compilers package
It is possible to use full C# 6.0 features in Visual Studio 2013 if you have Resharper.
You have to enable Resharper Build and voilá!
In Resharper Options -> Build - enable Resharper Build and in "Use MSBuild.exe version" choose "Latest Installed"
This way Resharper is going to build your C# 6.0 Projects and will also not underline C# 6.0 code as invalid.
I am also using this although I have Visual Studio 2015 because:
Unit Tests in Resharper don't work for me with Visual Studio 2015 for some reason
VS 2015 uses a lot more memory than VS 2013.
I am putting this here, as I was looking for a solution for this problem for some time now and maybe it will help someone else.
It seems there's some misunderstanding. So, instead of trying to patch VS2013 here's and answer from a Microsoft guy: https://social.msdn.microsoft.com/Forums/vstudio/en-US/49ba9a67-d26a-4b21-80ef-caeb081b878e/will-c-60-ever-be-supported-by-vs-2013?forum=roslyn
So, please, read it and install VS2015.
I am making a small external tool for Visual Studio that uses the following referenced assembly:
Microsoft.TeamFoundation.VersionControl.Client
My tool is built in Visual Studio 2012, so it uses the reference of that same version, 11.0.0.0. When I try to run the same tool in Visual Studio 2013, the file is missing because the version has changed in VS2013: 12.0.0.0.
Note that this happens when only Visual Studio 2013 is installed on the machine.
What I am trying to achieve now, is to have my program use the version that is available on the machine. So if the version 12.0.0.0 is found, use that; and if 11.0.0.0 is found, use that.
After some research I came across this link which said the following:
To successfully deploy your .NET Framework application, you must understand how the common language runtime locates and binds to the assemblies that make up your application. By default, the runtime attempts to bind with the exact version of an assembly that the application was built with. This default behavior can be overridden by configuration file settings.
This can be achieved by the use of a dynamic reference, as explained in that same topic.
While there is information on how to dynamically load references, I am unsure how to approach this.
Based on this I have some questions:
Is there any way for me to add one dynamic reference and have the machine it runs on decide which version it uses?
Are there any other ways to achieve the use of two versions where only one may be used on the machine?
Would an option be to build the application on a machine with VS2012 AND VS2013, and reference both versions?
Edit: Option 3 is not possible because Visual Studio complains about a reference to that component already existing.
Edit 2: If I add the reference as follows:
<Reference Include="Microsoft.TeamFoundation.VersionControl.Client" />
without the use of Version, Culture, etcetera; I get a compilation error saying there is a conflict between different versions of the same dependent assembly.
Edit 3: Setting the referenceversion to non-specific does not work either, as this is a buildsetting and not a runtime setting.
I have just installed the nuget package of Resharper and build the solution then I am getting these error on each Task type methods. It seems that it is because of two Threading.Task.dll files.
Error :
Error 87 The type 'System.Threading.Tasks.Task' exists in both 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETCore\v4.5\System.Threading.Tasks.dll' and 'C:\Users\emp70\Documents\Visual Studio 2012\Projects\FSOP\packages\JetBrains.ReSharper.SDK.8.2.1158\build\..\Bin\System.Threading.dll' C:\Users\emp70\Documents\Visual Studio 2012\Projects\FSOP\FSOP\ViewModel\DashBoardVM.cs 1604 22 FSOP
How to solve this conflict ?
Before installing Resharper everything was just working fine.
Unfortunately, this is a known issue with the SDK. ReSharper is a .net 3.5 application, and we're using a port of System.Threading.Tasks to get Task support. Sadly, this gives conflicts with a .net 4 project. This is something we're actively addressing in the next version - there are major changes to the SDK and the architecture in the works.
Sadly, there isn't an entirely satisfactory workaround. You can make your plugin a .net 3.5 plugin, but then you'll get a lot of warnings about .net 4 assemblies that are referenced but won't get used - you can safely ignore these, as they're essentially end user features that you won't need to reference in your plugin, but they're annoying (this is what I do). Alternatively, you can not use Task. Again, not ideal, but I've written quite a few plugins, and haven't had to use Task yet. YMMV.
Simply deleting/renaming the copy of System.Threading.dll within the packages folder should resolve the ambiguity, you should contact jetbrains to get it properly fixed.
I need to rebuild a set of custom TFS build activities, and am getting the following error. I'm under the impression from googling around that this results from MS pulling the Microsoft.Build.Engine package out of the 4.0 Framework and including it with the VS tooling.
The primary reference "Microsoft.TeamFoundation.Build.Workflow, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the .NET Framework assembly "Microsoft.Build.Engine, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which has a higher version "12.0.0.0" than the version "4.0.0.0" in the current target framework.
Any ideas what I can do about this? I am targeting the 4.5 framework, have VS 2012 and 2013 installed, though using 2012 to build this package.
Check the reference to Microsoft.Build.Engine or the reference path. The MsBuild binary and its dependencies has moved from the c:\windows\Microsoft.NET folder to: C:\Program Files (x86)\MSBuild\12.0\Bin
I had a similar problem, and, in general, Lee Higgitt's answer is correct. The reason is that Microsoft.TeamFoundation.Build.Workflow v.12 has a dependency on Microsoft.Build.dll v.12, which I've learned somehow requires that the build be done using Microsoft.Build.Tasks.v12.0.dll. If the MSBuild property VisualStudioVersion is set to 12.0 (e.g. when the sln is a VS 2013 sln), then Microsoft.Build.Tasks.v12.0.dll is used. In contrast, if VisualStudioVersion is set to 11.0 (e.g. when it's a VS 2012 sln), then
Microsoft.Build.Tasks.v4.0.dll is used. The v4 Tasks dll produces the error; the v12 Tasks dll doesn't. In general, then, upgrading the sln to VS 2013 will fix it.
However, if one is using a TFS build server, it's a different story. Even if VisualStudioVersion is 12.0, since C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe is used to do the build and only the v4 Tasks dll is present in that directory, the build is forced to use the v4 Tasks dll, causing the error to be produced.
You might think that forcing the build to use the x86 version of MSBuild would do the job, but, C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe still only contains the v4 Tasks dll!
From my command line testing, when the build is done with C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe, the v12 Tasks dll is present in that dir and is used, so the build works!
Also, I've oversimplified the problem above. I tried copying the v12 Tasks dll and Microsoft.Build.Utilities.v12.0.dll into
C:\Windows\Microsoft.NET\Framework\v4.0.30319, but that didn't allow the instance of msbuild in that directory to build my sln successfully.
In short, I think this must be a Microsoft bug. I'll create a ticket with them and update this thread as I learn anything.
Update:
Here's the issue on Microsoft Connect.
Update 2:
As one can see from the the issue on Microsoft Connect, for the TF Build case, if one uses the template that comes with TFS 2013, this issue is not repro'ed (though I haven't had a chance to confirm this myself yet). So, to fix this issue...
If it's happening locally, upgrade the solution to VS 2013.
If it's on a TFS build server, make sure the logic of the latest template from Microsoft is being used.
I've been having the same issue in Visual Studio 2012.
I've re-created my solution in VS2013 and all of the issues go away! Not really a solution but if you've got access to 2013 then I recommend you try it.
I'm new in monodevelop and I have a question.
I have some assemblies developed in Visual Studio 2010 in C# and I would like to use them with monotouch in Mac, my question is: do I have to use the source and generate the assemblies with monodevelop in Mac or just I need the assemblies and add them to my solution as a reference?
The framework profile used by MonoTouch was originally based on the Silverlight profile (aka 2.1) and was updated to include some, but not all, of the new API provided by the .NET framework 4.0.
As such you might be able to reuse assemblies, without recompiling them. That will depends if all the API are available, if you refer to assemblies not available in MonoTouch, under what profile (3.5 or 4.0) you're building the code...
However things would be a lot easier if you have the source code and are able to re-compile it inside MonoDevelop. That would provide you with debugging symbols (the .mdb files) also also catch, at compile time (not at run time), and fix code using any missing API (from MonoTouch).
You should be able to use the same assemblies as they are (no need for a recompile). If the assemblies depend on other nonstandard assemblies it might get tricky and you may have to deploy other assemblies along side the ones you want and then that may cause it's own problems if they are not open source or licenses are required to redistribute, etc.. Give it a shot, see what happens.