I just recently delved into Roslyn compiler stuff and I'm wondering about some possibilities. I'm trying to build Roslyn compiler from Roslyn repository using features/tuples branch and replace the needed DLLs in VS15Preview\MSBuild\15.0\Bin folder. But when I replace DLLs and build console app project I receive the following error message
Severity Code Description Project File Line Suppression State
Error The specified task executable "csc.exe" could not be run. Could not load file or assembly 'Microsoft.CodeAnalysis.CSharp, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Files which I try to replace: Microsoft.CodeAnalysis.dll, Microsoft.CodeAnalysis.Csharp.dll and csc.exe.
Is it possible to build your custom Roslyn compiler for C# and replace it within VS15 Preview?
One way of going about it is to set the CscToolPath msbuild variable to your new roslyn build's bin directory.
I find the msbuild commandline (e.g. Start > Developer Command Prompt) the most convenient for this. You can just cd into any solution directory on run:
msbuild /p:CscToolPath=<PathToYourRoslynBinDir>`
You can also do it inside a .csproj if you do it more often:
<PropertyGroup>
<CscToolPath>C:\your\roslyn\bin</CscToolPath>
</PropertyGroup>
Obviously, this only affects the build, not Visual Studio or it's intellisense. To hook that up, you need to follow the Trying Your Changes in Visual Studio guide in the Roslyn repo. You have to build one of the VSIX projects in the Roslyn solution. Running one of those projects launches an experimental instance of Visual Studio where you can play around with your changes.
M0sa's answer might work, however, that will only give you MSBuild enabled builds. If you also want to test it in VS, then you can follow Roslyn's own documentation. That page tell you how to replace the "intellisense" in Visual Studio (the VisualStudioSetup bullet), and the Ctrl-Shift-B "Build Solution" to actually run your solution (the CompilerExtension).
If you just want to try out your build of Roslyn, you can do that by opening Roslyn.sln in VS15 and then running the Roslyn project (with or without debugging). It will start a new instance of VS15, which uses your build of Roslyn.
Related
Yesterday I updated my visual studio 2017 from version 15.6.4 to 15.6.6 and then this error occured when i tried to run my program. Help me fix this please, i have no idea what to do. Please provide step by step procedure, thank you.
The "GetDependsOnNETStandard" task could not be loaded from the assembly C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\tools\net46\Microsoft.NET.Build.Extensions.Tasks.dll. Could not load file or assembly 'file:///C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\tools\net46\Microsoft.NET.Build.Extensions.Tasks.dll' 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.
Try to execute the command: "git clean -fdx" to clean up some (possible) trash file on your git repo.
Works for me.
I had the same error.
In my case, the error occurred because the one of my library assemblies which are downloaded was 0 bytes in size.
This meant the reference in visual studio was set, but the assembly was actually just an empty file.
I successfully used VS 2015 (including c++ / c#) in the past and downloaded now the new VS 2017. Building the project, I got several warnings such as:
(1) Severity Code Description Project File Line Suppression State
Warning The referenced component 'Microsoft.Data.Tools.Components'
could not be found.
(2) Severity Code Description Project File Line Suppression State
Warning Could not resolve this reference. Could not locate the
assembly "Microsoft.Data.Tools.Components, Version=15.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a,
processorArchitecture=MSIL". Check to make sure the assembly exists on
disk. If this reference is required by your code, you may get
compilation errors.
(3) Severity Code Description Project File Line Suppression State
Warning Could not resolve this reference. Could not locate the
assembly "Microsoft.Data.Tools.Schema.Sql.UnitTesting,
Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a,
processorArchitecture=MSIL". Check to make sure the assembly exists on
disk. If this reference is required by your code, you may get
compilation errors.
I tried now several options. Actually, the solution explorer shows under references the "Microsoft.Data.Tools.Components". I then changed the .NET target framework from 4.6.1 to 4.5.1 and the reference path to C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\Extensions\Microsoft\SqlDb\ without no progress.
Maybe, some could help .. many thanks.
Not sure if this would resolve this problem or if Sepp ever found a solution, but this problem sounds similar to one I had upgrading to 2017 on other projects. Adding updated MS Libraries via NuGet has worked for me.
Open NuGet Package Manager and search for Microsoft.Data.Tools to find Microsoft content similar to Microsoft.Data.Tools.Components.
There are two similar entries Microsoft.Data.Tools.UnitTest and Microsoft.Data.Tools.MsBuild
Try adding maybe the Microsoft.Data.Tools.MsBuild or both to your solution and recompile. These libraries sound like they are the same base, and may include the 'Component' content also. A Google found the same issue (i.e. https://social.msdn.microsoft.com/Forums/en-US/09f82922-2fe5-46cc-bc70-b63f137aec28/visual-studio-2017-warning-issues-?forum=vssetup, and the Microsoft.Data.Tools.MsBuild package includes content similar to that mentioned both above and there. The MsBuild states: "You can use SSDT Transact-SQL design capabilities to build, debug, maintain, and refactor databases." - so I'm thinking this may be an update to your older set. If it doesn't work, just unselect them to uninstall.
I am following the NUnit tutorial here.
My source files live in the folder C:\Users\Me\Documents\Visual Studio 2015\Projects\NUnitTest\NUnitTest. My NUnit DLL lives in the folder C:\Program Files (x86)\NUnit.org\framework\3.2.0.0\portable\nunit.framework.dll. I am certain that these paths are correct.
To compile the source file AccountTest.cs into a DLL, I ran the following commands:
cd C:\Users\Me\Documents\Visual Studio 2015\Projects\NUnitTest\NUnitTest
C:\Users\Me\Documents\Visual Studio 2015\Projects\NUnitTest\NUnitTest>csc /target:library /out:AccountTest.DLL /r:C:\Program Files (x86)\NUnit.org\framework\3.2.0.0\portable\nunit.framework.dll AccountTest.cs
However, I see these error messages:
error CS2001: Source file 'C:\Users\Me\Documents\Visual Studio 2015\Projects\N
UnitTest\NUnitTest\Files' could not be found.
error CS2001: Source file 'C:\Users\Me\Documents\Visual Studio 2015\Projects\N
UnitTest\NUnitTest\(x86)\NUnit.org\framework\3.2.0.0\portable\nunit.framework.dl
l' could not be found.
Any advice?
EDIT: I didn't forget to add a reference to NUnit inside of my solution. I also included the appropriate using statement.
It is because you did not quote the path to the NUnit assembly when you compiled from the command line. It should be this,
csc /target:library /out:AccountTest.DLL /r:"C:\Program Files (x86)\NUnit.org\framework\3.2.0.0\portable\nunit.framework.dll" AccountTest.cs
You should also know that the NUnit Console cannot run tests using the portable version of the framework at the moment. To do that, you need to create a self-executing test assembly using NUnitLite. For now, it would be easier for you to just use the .NET 4.5 version of the framework.
Is there any reason you are compiling at the command line? Visual Studio Community Edition is free and will handle compiling for you. If you are not on Windows, MonoDevelop is another good option.
Have you added a reference to your Solution?
right click Solution
hover over add
click reference
search for Nunit reference and add it
Also, make sure that you have added a using statement at the top of your project on all classes
I'm having an issue building a project that references a DLL located in the project's bin folder, which up until yesterday was building and running without issue.
The error I'm getting is fatal error CS0009: Metadata file 'c:\MyProject\bin\myClient.dll' could not be opened -- 'Error importing module 'myClient.netmodule' of assembly 'c:\MyProject\bin\myClient.dll' -- The system cannot find the file specified.' Intellisense is similarly complaining that The type or namespace 'Api' does not exist in the namespace 'Client' since it can't find the DLL.
Let me know if you think this is a duplicate, but I've viewed several similar posts and the solutions did solve my problem. Here are some examples:
Visual Studio 2010 — are you missing a using directive or an assembly reference?
VS2010 - Getting “type or namespace name could not be found” but everything seems ok?
Stymied by ASP.NET Compilation Error CS0009
Metadata file '…\Release\project.dll' could not be found in Visual Studio
Visual Studio 2010: Metadata file “…/Debug/Graph.dll” could not be found
Metadata file … could not be found error when building projects
Specifically, I've tried the following solutions (and combinations of these):
Cleaned and rebuilt my project.
Made sure that the target framework is not a 'client profile' version of .NET
Verifyied that the dll has been added as a project reference
Removed and re-added the project reference
Verified that the project is showing the DLL in the References section in Visual Studio
Repaired .NET
Verified the location of the DLL (it is in the local project's bin folder as given by the error)
Tried other versions of .NET
Closed and restarted Visual Studio
Rebooted my machine
Verified there are no hidden characters surrounding the 'using' statement
Removed all code changes since the last working build
Verified the settings in Configuration manager, including that 'Build' is checked
The project calling the DLL is a small class library that resides in a solution with one other small project (a console application). The DLL is an external DLL that I've been using successfully for several weeks in this project/solution. The error arises regardless of whether I build the project from the solution or by itself.
Any ideas about what could be going on?
Have you included bin folder in your project accidentally? If yes that might cause the issue. You can't include bin folder in your project as the bin folder will be created by the VS. If you accidentally include bin folder in your project, the bin project will be set to Copy to output which when you compile, the file is deleted and copied to output by Visual Studio that trigger weird behavior that some file is missing.
Hopes this help
Well I'm not sure exactly what happened here, but here is what finally resolved the issue:
A good-old-fashioned delete every single file and rebuild the project from those files from scratch. I gave +1 to some of the responses because they were useful to consider, and because there was probably a messed-up reference some where as Jonathon Wood suggested.
For about 2 weeks now, I have been unable to run any UnitTests (built in VS unit tests) for a project. Previously everything worked fine. The error message is:
Could not load file or assembly 'C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\MyProjectName.XmlSerializers.dll" or one of its dependencies.
The project references System.Xml.Serialization and uses the XmlSerializer class; just like many other classes/projects I've written. For some reason, only this project is affected. It builds fine, runs fine, I just can't run my unit tests.
I've checked the directory, and all the dlls in that directory are Microsoft dlls. The dll that it is looking for obviously is not a Microsoft dll.
Anyone have any ideas?
Edit:
It apparently has something to do with using the XmlSerializer and it generating that file automatically instead of using sgen.exe. Here is a link to the MSDN article. From what I've been able to find, it has something to do with using the serializer with generics. None of the sources I've found seem to offer any way to make it actually work.
First enable loader logging (using FUSLOGVW.exe from the SDK) to confirm what is not being found.
Then use Reflector on all your assemblies to find the one that is trying to load the non-existent assembly. If you find no such assembly it must be being loaded dynamically, in which case attaching to AppDomain.AssemblyResolve should allow you to identify where.
try to copy all your source files somewhere, then delete the project and try to make it from scratch. Maybe something happened with project dependencies
Is your computer 64bit? I got the same error when trying to run a 64bit dll with NUnit that was set to work as an x86 assembly (using corflags).
You can probably find out from the error message (use FUSLOGVW.exe lick Richard suggested).
If that is the case you can either sent the dll or NUnit to run as the correct assembly using corflags.
Solution
As it turns out, the problem was with VMWare. I installed the latest version of VMWare, and it installed it's tools to debug in a VM. Something it installed or changed caused this problem. When I uninstalled VMWare, the problem went away. So, I reinstalled VMWare without installing it's debugging capabilities and the problem did not come back.
Workaround:
I still have no idea why this problem suddenly started occurring, but I found a hack to make it work.
I had to go to project properties => Build Events and add this line to the Post-build event command line:
"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\sgen.exe" "$(TargetPath)" /force
This forces VS to generate the file. I then had to copy that file manually to the directory it was looking for it in:
"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies"
Now it I can run my tests and step through them. The problems I have now are 1) I have to remember to copy the dll to that directory every time I change something in the classes that I am serializing, and 2) I now get a ThreadInterruptedException when a test finishes running; thus 3) I can only run one test at a time.
Not a good solution, but at least I can limp through. Unfortunately, redoing everything, as Nikita Borodulin suggested, is not an option.