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.
Related
Before I start, I've tried all suggestions from the following and none work:
Integration testing ASP.NET Core with .NET Framework - can't find deps.json
https://zimmergren.net/unable-to-find-deps-json-dotnet-azure-devops/
So I'm trying to write some integration tests for dotnet 6. However, my WebApplicationFactory throws the following error:
System.InvalidOperationException: Can't find
'/repos/subscription-info-api/tests/SubscriptionInfoApi.Tests.Integration/bin/Debug/net6.0/...
System.InvalidOperationException Can't find
'/repos/subscription-info-api/tests/SubscriptionInfoApi.Tests.Integration/bin/Debug/net6.0/testhost.deps.json'.
This file is required for functional tests to run properly. There
should be a copy of the file on your source project bin folder. If
that is not the case, make sure that the property
PreserveCompilationContext is set to true on your project file. E.g
'true'. For
functional tests to work they need to either run from the build output
folder or the testhost.deps.json file from your application's output
directory must be copied to the folder where the tests are running on.
A common cause for this error is having shadow copying enabled when
the tests run. at
Microsoft.AspNetCore.Mvc.Testing.WebApplicationFactory1.EnsureDepsFile() at Microsoft.AspNetCore.Mvc.Testing.WebApplicationFactory1.EnsureServer()
at
Microsoft.AspNetCore.Mvc.Testing.WebApplicationFactory1.CreateDefaultClient(DelegatingHandler[] handlers) at Microsoft.AspNetCore.Mvc.Testing.WebApplicationFactory1.CreateDefaultClient(Uri
baseAddress, DelegatingHandler[] handlers) at
Microsoft.AspNetCore.Mvc.Testing.WebApplicationFactory1.CreateClient(WebApplicationFactoryClientOptions options) at Microsoft.AspNetCore.Mvc.Testing.WebApplicationFactory1.CreateClient()
at SubscriptionInfoApi.Tests.Integration.UnitTest1.Test1() in
/repos/subscription-info-api/tests/SubscriptionInfoApi.Tests.Integration/UnitTest1.cs:line
14 at SubscriptionInfoApi.Tests.Integration.UnitTest1.Test1() in
/repos/subscription-info-api/tests/SubscriptionInfoApi.Tests.Integration/UnitTest1.cs:line
16 at
Xunit.Sdk.TestInvoker1.<>c__DisplayClass48_0.<<InvokeTestMethodAsync>b__1>d.MoveNext() in /_/src/xunit.execution/Sdk/Frameworks/Runners/TestInvoker.cs:line 264 --- End of stack trace from previous location --- at Xunit.Sdk.ExecutionTimer.AggregateAsync(Func1 asyncAction) in
//src/xunit.execution/Sdk/Frameworks/ExecutionTimer.cs:line 48 at
Xunit.Sdk.ExceptionAggregator.RunAsync(Func`1 code) in
//src/xunit.core/Sdk/ExceptionAggregator.cs:line 90
My actual test code is extremely simple:
[Fact]
public async Task Test1()
{
await using var app = new WebApplicationFactory<Program>();
using var client = app.CreateClient();
var res = await (await client.GetAsync("/alive-test")).Content.ReadAsStringAsync();
Assert.Equal("Alive!", res);
}
As per the suggestions, I've made sure I'm directly referencing Microsoft.AspNetCore.Mvc.Testing -> 6.0.0 in my integration tests project. I've also tried the various tweaks to the .csproj files that were suggested but nothing seems to be working.
I'm stuck for things to try to debug this further, any ideas?
You are probably targeting the wrong namespace for Program in your test file (like I was).
I had to add the following at the end of my Program.cs file (last line) to make it visible to my test projects needing it:
public partial class Program { }
An example can be found here: minimal api testing example
I had the same problem, although for an entirely different reason.
I am using .net 6 but I deliberately chose to use an implementation that actually has a Program.cs file.
When I copied the code from the official MS integration test guide, I let VS pull in all the dependencies. The dependency used to resolve the Program.cs was not my own (PersonalSite for the sake of this answer), but one of MS's own implementation:
A small error on my part, sure, but maybe I can help somebody out.
For those who actually need the partial class implementation gimmick, the MS integ test guide I linked lists guidelines to do just that.
FWIW there is another approach that works as well (which doesn't require modifying code).
In your app's .csproj file add the following (Assuming your test project is called 'Tests'):
<ItemGroup>
<InternalsVisibleTo Include="Tests" />
</ItemGroup>
This allows your Tests project to see your Program.cs file.
change your Program class access specifier in your api from internal to Public
I was trying to move a build to a new build server and I was getting the following error:
..\packages\DllExport.1.5.2\tools\net.r_eg.DllExport.targets(70,7): error MSB3073: The command "NSBin.bat "" "SPDbUtil" "true"" exited with code 9009.
'NSBin.bat' is not recognized as an internal or external command, (TaskId:52)
The project has a reference to the following DllExport:
In looking at the following .targets file, it appears when running the Exec command the $(DllExportMetaLibFullPath), where the NSBin.bat file lives, is blank at the time it is called:
When I checked out the project and try and build it, it fails the first time and succeeds on consecutive builds.
If I add "echo $(DllExportMetaLibFullPath)" to the <PreBuildEvent> of the project- it builds successfully the first time.
Does anyone know why this happens? Am I missing something? BTW: this is an older project that I was trying to move to a new build system. The previous builds were completing because the build defs "Clean" option was "false". I can keep the echo in there but would be nice to know the correct way to handle this or have a definitive answer for the devs.
Thanks
I have a C# WPF application. It uses a small commercial framework (https://www.inosoft.com/en/product/product-features/).
I'm building this application both locally and via a buildserver (Azure pipelines). I use a marketplace task to change the assemblyinfo.cs before building: https://marketplace.visualstudio.com/items?itemName=bleddynrichards.Assembly-Info-Task
The build server executes the following tasks:
NuGet restore
Inject/Edit assemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion with the right version info
Build
Now when I run this application, it starts up and runs for a while.
Quickly after starting I hook the VS debugger into the process.
Then all of the sudden the application crashes:
This is weird, because when I build locally, this runtime error does not occur.
Note that i set all properties to the same values for testing:
AssemblyVersion: 1.2.3.4
AssemblyFileVersion: 5.6.7.8
AssemblyInformationalVersion: 9.10.11.12
I then use Telerik justAssembly to compare the build output from my local build and the buildserver:
As we can see the local output (on the left) does not have a version added to the Application.LoadComponent(..) whilst the build server output (on the right) does.
public void InitializeComponent()
{
if (!this._contentLoaded)
{
this._contentLoaded = true;
Application.LoadComponent(this, new Uri("/HmiMetis;component/views/app.xaml", UriKind.Relative));
}
}
This means that this is the root cause of the runtime exception.
I find it weird that the build process on my local machine differs from the build server output. Both (should) use visual studio 2017 to build. Why does the buildserver add the version to the uri of loadComponent and my local machine does not?
Anyways, I need this exception gone.
Therefore I think the easiest way would be to force the buildserver to not add the version information under any circumstances. Is this possible and how?
Edit:
I Found a relating issue report that may have something to do with this:
https://github.com/dotnet/core/issues/3189
I am trying to analyse a solution with Roslyn, with MSBuildWorkspace.
The solution is a new solution, with 2 class library projects in them, one referencing the other.
They are created in Visual Studio 2017, .Net 4.6.2.
When I open the solution, I receive two generic errors in workspace.Diagnostics, both are :
Msbuild failed when processing the file 'PathToProject'
There is nothing more in the diagnostics or output window, to indicate WHY it failed to process the project file.
The code for opening the solution:
namespace RoslynAnalyse
{
class Program
{
static void Main(string[] args)
{
LocalAnalysis();
}
private static void LocalAnalysis()
{
var workspace = MSBuildWorkspace.Create();
var solution = workspace.OpenSolutionAsync(#"D:\Code\Roslyn\RoslynAnalyse\SolutionToAnalyse\SolutionToAnalyse.sln").Result;
var workspaceDiagnostics = workspace.Diagnostics;
}
}
}
The version of Microsoft.CodeAnalysis is 2.0.0.0.
Does anybody have any idea why MSBuild failed, how I can get more information ?
When MSBuildWorkspace fails to open a project or solution this way, it is almost always because the application using MSBuildWorkspace does not include the same binding redirects that msbuild.exe.config has in it.
MSBuild uses binding redirects to allow tasks (typically already compiled C# code using possibly different versions of msbuild API libraries) to all use the current msbuild API's. Otherwise, msbuild gets runtime load failures.
The solution is to add an app.config file to your project and copy the binding redirects (the assemblyBinding section of the msbuild.exe.config file) into your file.
From C# code I'm trying to retrieve all the namespaces from powershell... (Later more complex things, like creating namespaces)
PowerShell ps = PowerShell.Create();
ps.AddCommand("Import-Module").AddArgument("ServiceBus").Invoke();
var result = ps.AddCommand("Get-SBNamespace").Invoke();
Above code gives the following exception:
The 'Get-SBNamespace' command was found in the module 'ServiceBus',
but the module could not be loaded. For more information, run
'Import-Module ServiceBus'.
Does anyone know how to solve this error?
CURRENT STATUS: after some debugging I've found that no modules are loaded by default in the PowerShell object. Using the code:
InitialSessionState iss = InitialSessionState.CreateDefault();
iss.ImportPSModule(new string[]{#"serviceBus"});
PowerShell ps = PowerShell.Create(iss);
doesn't work to load the service bus module. Also the code:
ps.AddCommand("Import-Module").AddParameter("-Name", "serviceBus").Invoke();
doesn't work to import the service bus module. Running Visual Studio in administrator mode also doesn't make a difference
Thanks in advance
You didn't say which version of Visual Studio you're using. If it's VS 2012, when you tried the x64 platform target did you make sure that "Prefer 32-bit" was not checked? Even if it was not checked try checking it, saving the project configuration, clearing it and saving again - this worked for me on another project.
UPDATE
It's been suggested elsewhere that there's a bug in VS2012 that shows "Prefer 32-bit" as greyed-out and unchecked when it's actually active. I'm running Update 2 and I don't see that. But it sounds like you might be. I suggest you edit the .csproj file directly.
Whilst "Platform Target" is set at "Any CPU", in Solution Explorer, right-click on the Project name (or, with go to the PROJECT menu) and select "Unload Project". Project files will close and Solution Explorer will display project name (unavailable) > The project file was unloaded:
Right-click on the Project name again and select "Edit project name.csproj". The file is XML and mostly comprises PropertyGroup and ItemGroup elements. In a console project, the first PropertyGroup usually contains a Platform element which should read AnyCPU if you followed my instructions above. The next two PropertyGroups are normally for Debug and Release configurations. If you've added another configuration, it will have its own PropertyGroup. In each of these, look for an element which reads:
<Prefer32Bit>true</Prefer32Bit>
What you should have is an element which reads:
<Prefer32Bit>false</Prefer32Bit>
Either change it or insert it (in each configuration ProjectGroup), save the file and close it. Back in Solution Explorer, right-click the project and select "Reload Project". Let me know if that solves it. You can confirm your PowerShell is now running 64-bit by get the result of
[System.IntPtr]::Size
e.g.
ps.AddScript("[System.IntPtr]::Size");
which will be 4 in an x86 process and 8 in an x64 process.
Which my project set up like this, I was able to load ServiceBus using:
ps.AddCommand("Import-Module").AddArgument("ServiceBus");
Hopefully, you will, too.
I don't have ServiceBus installed so I can't verify exactly what you've tried but
ps.AddCommand("Import-Module").AddArgument("ActiveDirectory").Invoke();
worked for me, so your original syntax looks good.
Just to test for failure, I tried:
ps.AddCommand("Import-Module").AddArgument("CheeseDirectory");
ps.Commands.Commands[0].MergeMyResults(PipelineResultTypes.Error, PipelineResultTypes.Output);
var importResult = ps.Invoke();
foreach (PSObject result in importResult)
{
Console.WriteLine(result);
}
and got
The specified module 'CheeseDirectory' was not loaded because no valid
module file was found in any module directory.
Have you tried similar?
Do you take care of your Assembly target in your C# program (x86 versus X64). The module may exist in one target, not in the other. PowerShell exists in both.
Seems you're trying to import some modules and execute the cmdlet or function inside the module, right?
So I think you could try the following code:
PowerShell ps = PowerShell.Create();
Assembly ass = Assembly.LoadFile(#"yourServiceBus.dll");
ps.AddCommand("Import-Module").AddParameter("Assembly", ass).Invoke();
var result = ps.AddCommand("Get-SBNamespace").Invoke();
Hope this could help.