❔ Using Roslyn from a 'single-file' app
For long-winded reasons, I need to publish my Roslyn-powered code-indexing app as a 'single-file' deployment (for clarity, I don't mean an app with one source file, I mean an app that is published as a self-contained executable, with the .NET runtime bundled).
This might sound counter-intuitive as, by definition, Roslyn needs access to the .NET SDK in order to actually analyse projects. It is guaranteed that there is a .NET install at a known path on the system i'm going to be deploying onto, however the dotnet CLI on said machine is broken (long story, not easy to fix).
In theory, I should be able to point to the dotnet install with MSBuildLocator.RegisterDotNetPath (as MSBuildLocator can't find VS installs when called from a single-file app) however i'm getting different behaviour when running the self-contained version as opposed to the default build.
When I run the app normally, it works correctly (i.e. can open and analyse projects).
When I try to open a solution from the self-contained app, it fails with the following (not very helpful) message:
One or more errors occurred. (The path is empty. (Parameter 'path'))
I've validated the solution it's trying to open - if I try build the solution directly, with dotnet, it builds fine with 0 errors/warnings, but Roslyn chokes on it.
I presume this must be because of the single-file deployment, but without better error messaging i'm a bit stuck. My question is: how might I go about debugging this and has anyone had success using Roslyn from a single-file app (can I include the bits of the .NET SDK required by roslyn in the single-file deployment? which bits need to be included, etc.)19 Replies
It's really hard to know what is happening with just this error message and this info. You might get lucky in #allow-unsafe-blocks I guess.
But if I were you I'd add more loggings to your application to know where exactly this is happening and try to debug it by attaching to the process. Make sure to use this option:
https://learn.microsoft.com/en-us/dotnet/core/deploying/single-file/overview?tabs=cli#include-pdb-files-inside-the-bundle
To include the pdb file in the assembly.
Create a single file for application deployment - .NET
Learn what single file application is and why you should consider using this application deployment model.
What is the purpose of the app?
Or to be more specific: do you really need to use msbuildworkspace?
It's pretty much an LSIF indexer (different format, same idea). We want to produce an index of all C# code in our codebase. The indexer i'm writing is given a list of solution paths - it's job is to open each one and visit all the symbols, writing facts about them to a DB.
I'm not sure whether I need to use msbuildworkspace (what are the alternatives?).
Ah, then yeah, you'll want to use msbuildworkspace
Unfortunately, with the constraints you have in your machine though, you're making it extremely difficult to use
To be clear: this has nothing to do with single-file
It has everything to do with your chopped-up sdk
What do you mean by 'chopped up' sorry?
"the dotnet cli on said machine is broken"
You need an actually working environment to use msbuildworkspace
You could try deploying https://github.com/jaredpar/xcopy-msbuild, and registering that as your msbuild instance, but you're definitely in a "no warranty" area
Ah, right. Yeah, it's a pain.. we have a version of the .NET SDK checked into source-control. Our in-house build system calls this checked-in .NET to build projects, so devs don't have to install .NET / worry about correct versions etc.
The problem is with the CI environment, as I understand it, is that the Linux image we use in CI (CentOS 8 Stream) provides copies of some .NET packages that conflict with those that the checked-in .NET provides, which breaks the dotnet CLI
(see this MSDN https://learn.microsoft.com/en-us/dotnet/core/install/linux-package-mixup?pivots=os-linux-ubuntu#solutions)
If I had control over the environment, I could follow the instructions in that article to fix it, but CI is very locked down (no external internet access etc.).
I was trying to work around this problem by building something that could 'run anywhere', I thought single file + pointing MSBuildLocator the checked-in .NET might work, but it sounds like this might be a non-starter.
Troubleshoot .NET package mix ups on Linux - .NET
Learn about how to troubleshoot strange .NET package errors on Linux. These errors may occur when you run the dotnet command.
Without debugging in the environment, it is going to be extremely painful to fix
I'll have a look at xcopy-msbuild, maybe I can use it or build something similar. In theory, everything needed is available in the repo - all the reference SDKs are checked in somewhere, all the NuGet packages are checked in somewhere (we use a nuget.config to ensure restore uses the local copies etc.)
Everything about this project is painful.. the .NET dev experience is non existant lol, no debugger in the dev environment, let alone CI. No IDE support either because our dev environment breaks omnisharper
I'm not sure why it would break omnisharp, there's a setting for what dotnet to use
But also, checking in all this stuff seems very weird to me
It's our virtualised file-system that breaks omnisharper. The repo is much too large to be practical to download in its entirety.
Like having the whole repo in Dropbox essentially
Yeah, I presume it's because our dev boxes can't talk to the external internet either
We're talking something as big as windows here?
I would assume larger, it's a "megarepo" of all the company's code, and it's a very big company
That's... A very bold assumption, but I see
Just saw your verified Microsoft badge aha, you'd definitely know better than me.
I work for a similar sized company
(sorry for being vauge, I don't want to dox myself or break my NDA -_- )
Okay, I checked out of curiosity, looks like Windows edges out our repo, but only just!
But we have a different (the main) megarepo that is bigger
That's going off a 350GB figure I found on some Microsoft article, but it's a few years out of date
I don't work on windows, so that's the best number I'd have either
Thanks for your help anyway, time to reconsider the portable app and perhaps go the bureaucratic route to try get CI fixed
Wish me luck 🙃
Good luck 
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.