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.
Related
I have written a small ORM assembly for private purpose and wanted to check the connection string.
I had created a console application and add a reference to the assembly as I always did.
Project explorer has no warning with the file, object explorer sees all my types and namespaces in the assembly. But compiler can't resolve this reference for some reasons and I don't understand why.
I restarted Visual Studio (Express 2013) but it did not help.
Can somebody get an idea why it can't resolve that assembly reference?
My problem was in different versions of .Net: .dll had been complied for .NET 4.6.1 and Project for .NET 4.5.
I have checked the properties of a dll and there was 4.0 runtime version setted so i was sure that version is fine.
Only compilation warning helps me to realize the reason of this problem.
Unfortunatly i get used to skip them and didn't read it right after a compilation.
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.
We developed a large solution containing ~35 projects with VS 2010, now we are thinking about migrating to VS 2012 Ultimate.
I converted the solution file to VS 2012 and generally, everything works fine.
But whenever I open the solution, I get some warnings on a certain project A in the solution:
"The project X cannot be referenced"
"The project Y cannot be referenced"
...
where A has project-references to X and Y.
When I build the solution, I get errors that the Metadata of each respective DLL could not be found.
When I look at the references in the solution explorer, they are marked with a yellow warning-symbol. As soon as I simply click on the reference, the warning goes away and the icon looks normal. Then I can build without errors!
The problem occurs each time I open the solution, the affected projects are always the same.
Did anyone else experience this odd behavior?
Deleting and adding the project references again did not help...
Thank you in advance.
EDIT: I checked the csproj file of the referencing project and I wonder that all project reference GUIDs having the above problem are written lowercase, other projects are uppercased.
<ProjectReference Include="..\Presentation.Net\Presentation.Net.csproj">
<Project>{04004c6b-76c8-4f2d-9fcf-5a866bb80fd4}</Project>
<Name>CMS.Presentation.Net</Name>
</ProjectReference>
While within the solution the GUIDs are uppercased:
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Presentation.Net", "Presentation.Net\Presentation.Net.csproj", "{04004C6B-76C8-4F2D-9FCF-5A866BB80FD4}"
Any ideas?
VS 2012 dropped support for some of the older project types. Not all of the VS 2010 project types are supported in VS 2012. For instance, the MSI setup project types have been replaced by InstallShield LE project types. Check the compatibility list here and see if any of your failing project types are an issue.
This pointed me into the right direction.
Visual Studio 2012 Randomly reporting: "The referenced component X could not be found"
At least the warnings go away. Have to check whether the metadata errors will occur again.
When I ran into this problem, it was due to differing versions of .NET between the projects. You need to make sure that the project you are trying to reference has a compatible .NET version with the current project.
For example if your target project is .NET 4.5.2 and the project you reference is on 4.6, you can get this error as the referenced project is using components that your current project cannot access.
To solve it, simply go to the target project's properties and select the correct compatible version of .NET. For all my projects in my solution I maintain the same .NET version for each of them, especially if they are referencing each other.
Try to clean the project/solution and then build it.
I found this problem on my C# project which I started at Visual Studio 2010, when I go to another PC I use in 2008, I open the project.csproj:
A get or set accessor expected
and warning:
The referenced component 'Microsoft.CSharp' could not be found.
I thought that it was about .NET Framework or Microsoft.CSharp is not located, because it says that:
Could not resolve this reference. Could not locate the assembly "Microsoft.CSharp". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors
but I'm not sure about the problem, can you guys give me a solution? Really appreciated.
It sounds like you are targeting .NET 4.0 in the project, and then trying to load it in VS2008 which only targets up to .NET 3.5.
If you need to use the project in VS2008, then you should re-target the project at .NET 3.5:
and then remove any incorrect references (they'll probably have yellow warning triangles on them anyway).
The A get or set accessor expected also suggests you're using new C# syntax, for example dynamic. If you need to target older C# compilers, you'll have to not do that. If you are using multiple IDE versions and it is being a problem, then to ensure you don't do that accidentally you can set the language version for the project via Project Properties -> Build -> Advanced:
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.