In a console application I have been trying to get OpenSolutionAsync to work for a couple of weeks now without success.
Finally I remembered to look at the roslyn-sdk repository which contains samples. I locally run the sample called SolutionExplorer and it works perfectly. I can choose a solution file and it can open the solution.
Given that this sample works, I decided to make my console app similar to it. So I copied the MSBuildService and WorkspaceService (just changing the logging behavior) to my console application. Changed my console app to target v4.6.1 of .NET Framework. Referenced the exact same nuget packages. I made sure to delete the bin folders and also compared the bin folder from the sample with the bin folder generated for my project. They are the same.
And yet, when I hit the line to OpenSolutionAsync(), my console application just exits the process.
What am I doing wrong?
More info:
I copied the project here to make it easily reachable for you. Please provide two parameters to run the project e.g:
callerid.scanner.exe -p "<path to some solution>" -d "<documentNameToFindInSolution>"
It exits the process on line 97 of WorkspaceService
A few things, sorry it VB but you should get the idea. The important thing is to get the right instance of MSBuild and trap the errors.
Property MSBuildInstance As VisualStudioInstance
' Get all instances of MSBuild
Private ReadOnly visualStudioInstances() As VisualStudioInstance = MSBuildLocator.QueryVisualStudioInstances().ToArray()
' Pick the instance of MSBuild you want
MSBuildInstance = visualStudioInstances(???)
MSBuildLocator.RegisterInstance(MSBuildInstance)
Using Workspace As MSBuildWorkspace = MSBuildWorkspace.Create()
AddHandler Workspace.WorkspaceFailed, AddressOf MSBuildWorkspaceFailed
Dim currentProject As Project = Workspace.OpenProjectAsync(FileName).Result
' Do something with the project
End Using
' Print message for WorkspaceFailed event to help diagnosing project load failures.
Private Sub MSBuildWorkspaceFailed(_1 As Object, e1 As WorkspaceDiagnosticEventArgs)
If MsgBox(e1.Diagnostic.Message, MsgBoxStyle.AbortRetryIgnore, "MSBuild Failed") = MsgBoxResult.Abort Then
End
End If
End Sub
You need to register a msbuild location with the MSBuildLocator class. This will allow the MSBuildWorkspace to open solutions and projects. Long story short: it needs to know where msbuild is because it uses it to load projects.
I would place the following code in the constructor of your service
// Attempt to set the version of MSBuild.
var visualStudioInstances = MSBuildLocator.QueryVisualStudioInstances().ToArray();
var instance = visualStudioInstances.Length == 1
// If there is only one instance of MSBuild on this machine, set that as the one to use.
? visualStudioInstances[0]
// Handle selecting the version of MSBuild you want to use.
: SelectVisualStudioInstance(visualStudioInstances);
_logger.WriteLine($"Using MSBuild at '{instance.MSBuildPath}' to load projects.");
// NOTE: Be sure to register an instance with the MSBuildLocator
// before calling MSBuildWorkspace.Create()
// otherwise, MSBuildWorkspace won't MEF compose.
MSBuildLocator.RegisterInstance(instance);
Found the problem.
I was using nuget package CommandLineParser. It has to do with usage of async while triggering the action with CommandLineParser. When I removed async and called OpenSolutionAsync().Result instead, it works.
It seems like CommandLineParser has no support for async implementation. Then OpenSolutionAsync just quits the process when called with await within CommandLineParser's WithParsed method.
This cost me weeks to figure out..
Thanks for your answers anyways, #Jonathon Marolf and #Paul Cohen.
So I have this really simple test:
[TestMethod]
public void CheckAllParametersExist()
{
try
{
new ParametersService().Get();
Assert.IsTrue(true);
}
catch(Exception ex)
{
Assert.Fail(ex.Message);
}
}
ParametersService().Get() runs through a parameters class finding all the properties and tries to populate them with values from a database. Occasionally when we release the website we might forget to publish some values, so I wanted a unit test in Bamboo to identify any parameters we may have missed.
To the crux of my problem: In Visual Studio 2017 the unit test passes fine. With MSTest is fails with:
Assert.Fail failed. The type initializer for 'System.Data.Entity.Internal.AppConfig' threw an exception.
Looking this particular error up it looks like I've got the wrong or mixed versions of EntityFramework. Having tried to fix this myself I have removed Entity framework from the Tests project nuget and app.config, then under the solution I consolidated the EntityFramework nuget and included Tests project again, still the same error. App.config shows version 6.0.0.0, nuget has installed 6.2.0
I am stuck, if anyone can suggest any solutions or identify any reasons why I might be seeing this problem I would be greatful.
Fyi: I am running MSTest with /testcontainer:tests.dll in the Tests project bin output debug folder.
So it turns out the problem was with the App.Config. The problem is that we have some sections of the configuration loaded from external files. In this case connection strings. In VS it loads the config file for connections strings just fine. In MSTest it copies the DLLs to another folder but doesn't include the folders/config files.
Also MSTest has now been retired, as of VS2013 we should be using VsTest.console, however Bamboo hasn't caught up with that yet.
I am trying to retire my in-house logging utility in favour of something 'off the peg', specifically log4net. I have it all working, except that I can't get it to work when I'm running my tests (specifications) in the ReSharper test runner.
I'm using MSpec (Machine.Specifications) as my test framework. If I understand things correctly, I get an assembly-level setup by implementing the IAssemblyContext interface. So, here's my assembly setup:
public class AssemblySetup : IAssemblyContext
{
public void OnAssemblyStart()
{
Trace.WriteLine("In assembly setup");
var fullPath = Path.Combine(Environment.CurrentDirectory, "log4net4mspec.config");
var fileInfo = new FileInfo(fullPath);
XmlConfigurator.Configure(fileInfo);
var log = LogManager.GetLogger("Assembly Setup");
log.Info("Logging configured");
}
public void OnAssemblyComplete() {}
}
I put the Trace.WriteLine() in there to verify that the code executes, and guess what? It doesn't! In the test results, nothing comes out:
The line that comes out from TiGra.Diagnostics is my 'old faithful' logging utility, which I am trying to retire. Not a squeak from log4net, or from that trace statement in my assembly setup. If I set a breakpoint on it and debug the tests, then the breakpoint isn't hit either, all of which indicates that the assembly setup isn't running.
Am I doing it wrong, or is something fishy going on here?
UPDATE
Using the console runner, and watching the trace output with DebugView, I get this coming out:
[11704] In assembly setup
[11704] Assembly Setup: INFO - Logging configured
[11704] Initializing logging
[11704] Assembly Setup: INFO - Logging configured by with_log4net
[11704] TA.[TopSecret].Serial.SerialChannel: INFO - Starting transaction, timeout=00:00:02 txMsg=:MS#
[11704] ===== TiGra.Diagnostics Initialized: Default TraceLevel = Verbose =====
So that looks like it is working and the assembly setup is working in the console runner. This is enough to make me doubt myself slightly, but "my" diagnostics has always worked for me in this situation so I'm not sure what's going on. Should I use the ConsoleAppender with MSpec instead of the Trace appender?
It should work, I remember adding this specifically to one of the ReSharper runners of the 0.5.x era.
I guess you have tested with the console runner as well?
What log4net appenders are configured?
We use unit test to test a component which is using Autofac to inject all the dependencies and instanciate objects. We use auto section in the configue file for the configuration. The MSTest runs very well within Visual Studio and through command line.
However, after we put the unit test to run through the MSTestRunner plugin within Jenkins for continutes build purpose, the following exception is through out:
"System.ArgumentException: The configuration section 'autofac' could not be read. at Autofac.Configuration.ConfigurationSettingsReader..ctor(String sectionName) "
This is a similar issues raised before and replied as have been fixed already.
The autofac version we are using is 2.6.3.862.
Thanks
I have a c# solution with the following structure:
mySolution
myProject
myProject.MSTests
References
Microsoft.VisualStudio.QualityTools.UnitTestFramework
sutMSTests.cs
sutMSTests.cs:
[TestClass()]
public class sutMSTests
{
[TestMethod]
public void MyTest0()
{
Microsoft.VisualStudio.TestTools.UnitTesting.Assert.AreEqual(4, 2 + 2);
}
}
When I try to run the tests via Test, Run, All Tests In Solution, I get the following on the VS2008 status line:
No tests are run because no tests are loaded or the selected tests are disabled.
Test, Windows, Test View shows no tests.
Note: I created the tests manually (works for xUnit.net) instead of using Microsoft's wizards.
I've compared my hand created MSTest setup to the setup another test that I generated using the wizard and they appear to be sufficiently similar.
Question: What are the most likely causes of the error message above?
Edit 2010-02-25: More information:
I right clicked the Solution Items folder, and choose Add, New Project, type Test Projects,Test Documents::Visual Studio Test Project template.
The new project's default do nothing test "TestMethod1" was detected and passed.
However, my test did not show up ... so I copied and pasted my test method into the default test test project "TestProject1".
My test was detected in "TestProject" BUT not in its original location.
I closely compared the files, organization, and settings of "TestProject1" with my hand created test project.
At this point, I am guessing that some setting gets made by the Visual Studio Test Project template that is not easily detectable.
imo, it should be just as easy to create a test project by hand as it is to create one with the Visual Studio Test Project template.
please note: I'm not saying that I'm against using the Visual Studio Test Project template; for me, I like to understand what's behind the curtain since this makes me imho a much better programmer.
Another one for the googlers - this one turned out to be my problem, and it's embarrassingly boneheaded of me. Make sure that your test project is set to build in whatever solution configuration you're using. If the test assembly isn't being built, VS won't be able to find any tests in the non-existent assembly, and you'll bang your head against the wall for a while :-)
Possibly a bit late, but this question googles up well, I thought I'd throw some crumbs in for future googlers.
Bryan Cook suggests checking the ProjectTypeGuids in his blog post about Manually creating a MS Test Project. Apparently the magic GUIDs you need are {3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC} for c# and {3AC096D0-A1C2-E12C-1390-A8335801FDAB};{F184B08F-C81C-45F6-A57F-5ABD9991F28F} for VB. See his blog post for more details.
In case the blog post ever goes away you need to add the following element in the main property group in the csproj file:
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
Another idea for the Googlers out there. My problem was trying to get ignored tests running again. Same MS error message occurs if you remove the Ignore label. Does not automatically re-enable the test. This article takes you through the last step. http://richallen.blogspot.com/2008/05/ms-test-re-enabling-ignored-tests.html
The fix is simple, even though it shouldn't be needed, if Visual Studio worked as it should.
To sum up what others have contributed, particularly in this article, here's what ultimately worked for me:
Use the Configuration Manager to make sure your test project is selected to build in whatever configuration and platform you're using (ex: configuration=Debug and platform=x86)
Make sure your method belongs to a [TestClass] and that it's both marked [TestMethod], and NOT using the attribute [Ignore]
Use Test View to find your test.
Open your Properties window (F4), and make sure your test is enabled
The original poster did do this, but I arrived here after not having done this:
Be sure that [TestClass] is declared at the top, public in scope:
namespace XYZ.API.Repository.Tests
{
[TestClass()]
public class ClientTests
{
I was receiving the same message and it turned out to be that I had my unit test project on a network drive. Once I moved it local it ran fine. Just something to try if you get this error.
John
I've just manually done this:
Created a new C# class library project with the following code:
namespace SO_Answer
{
public class Class1
{
public void Test()
{
var k = "Hello";
}
}
}
Saved the project and then went to 'File->Add->New Project' and chose 'Test Project'. After VS created the unit test project, I added a reference to the class library project I created earlier.
In my test I have this code:
namespace Unit_Test
{
/// <summary>
/// Summary description for UnitTest1
/// </summary>
[TestClass]
public class UnitTest1
{
/// <summary>
///Gets or sets the test context which provides
///information about and functionality for the current test run.
///</summary>
public TestContext TestContext { get; set; }
#region Additional test attributes
// You can use the following additional attributes as you write your tests:
// Use ClassInitialize to run code before running the first test in the class
// [ClassInitialize()]
// public static void MyClassInitialize(TestContext testContext) { }
// Use ClassCleanup to run code after all tests in a class have run
// [ClassCleanup()]
// public static void MyClassCleanup() { }
// Use TestInitialize to run code before running each test
// [TestInitialize()]
// public void MyTestInitialize() { }
// Use TestCleanup to run code after each test has run
// [TestCleanup()]
// public void MyTestCleanup() { }
#endregion
/// <summary>
/// The test method 1.
/// </summary>
[TestMethod]
public void TestMethod1()
{
var f = new Class1();
}
}
}
The only code I added was the a using statement and the var f = new Class1(); statement. Looking at the MSTest runner, I can see TestMethod1 appear.
I can't think of a reason why your unit tests are not being picked up. The only time I've had this is because I was using the MSTest runner to try and view NUnit tests by mistake. Try starting from scratch.
This could be another reason. Check whether the solution is running on 64bit. If so change it to x86.
This must be a bug and is an absolute pain especially as you have to reenable every single test method individually. However a bit iof lateral thinking produced a better solution - rename the test class and rebuild. Then rename it back. Seems to work.
Ooops - no it doesn't. Renaming the class works but when it's renamed back it reverts to the original settings.
The trick is to close down Visual Studio and delete the .vsmdi (visual studio test meta data) file. This will be regenrated.
When you run into this issue, in Visual Studio, you have to create a Test Project.
1. Select Test in Tool bar and choose "New Test". Create your project and at this point create your test method. It should work after this point.
For posterity: I just found that marking tests as static made them silently fail to appear in the test list. Apparently that isn't allowed.
None of the other answers worked for me. I kept getting the following message in the output window:
------ Discover test started ------
========== Discover test finished: 2 found (0:00:00.1310428) ==========
No tests found to run.
In my case, the problem only occurred after I created a new configuration called 0-Local. I had to add <DebugSymbols>true</DebugSymbols to the relevant section of my csproj file, so it looks like this:
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == '0-Local|AnyCPU'">
<DebugSymbols>true</DebugSymbols>
<OutputPath>bin\0-Local\</OutputPath>
</PropertyGroup>
Do you have a VSMDI file in your solution? I believe this file is required (NOT VERIFIED).
this is typical problem i have faced too. but the easiest solution I followed as my own is...just to build the project once and rebuild it again. so that you can resolve it.
Had this same issue but reading over the previous answers, everything looked good.
In my case, I had just run the test suite made a small change, built the solution and tried to run the test. No go. I tried building a couple more times and looking for problems other people had tried. Still no go.
I hit enter in one of my test methods to add a new and hit F6 to build the solution and clicked run Unit Tests.
Bingo! Everything ran smoothly.
I was making use of a public TestContext TestContext method to write to the test output and changed the scope to private. This made every test not discoverable. Changing it back to public helped.
Another one for googlers using NUnit, especially those who have migrated from MS Unit test to NUnit. Please remove the project type Guids that are identifying the project as MS Test project from the project file.
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
If your code is CLI (managed c++) and your test class inherits from an abstract base class, make sure that your test class implements the base's pure virtual method.
if you didn't implement it, you may see the "no tests found to run" message.