bflattened / bflat

C# as you know it but with Go-inspired tooling (small, selfcontained, and native executables)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Rider LSP and Analytics does not work

itsmagu opened this issue · comments

commented

image
I get this error in my IDE

commented

Infact the whole repo is a error fest in Rider, is this not meant to be used with the Jetbrains IDE?
Does it work as intended in visual studio?

commented

image

Infact the whole repo is a error fest in Rider, is this not meant to be used with the Jetbrains IDE? Does it work as intended in visual studio?

My guess is the nuget dependecy wasn't restored. An extra step is needed: https://github.com/bflattened/bflat/blob/master/BUILDING.md#building-bflat-from-source

commented

Okay following these steps removed most of the errors but I still get these:
image

commented

Okey, bumping the project back to 8.0 from 6.0 removed the last 2 errors!
Sorry about that the BUILDING.md made me believe it needed 6.0

commented

My second question is how do I work with zerolib?
I want to be able to change it for whatever needs I have.
image

commented

I have now tested creating a blank program and copying over zerolib into it, added the preprocessor defenitions, and setup the project for use with bflat (with the nuget.config now). But I get these errors now:
image

commented

running bflat build --stdlib:none compiles so that is good, unless I open rider once. Since then the obj folders will be filled with generated files that bflat will exit on since they are not meant to be compiled and make no sense to bflat.
image

running bflat build --stdlib:none compiles so that is good, unless I open rider once. Since then the obj folders will be filled with generated files that bflat will exit on since they are not meant to be compiled and make no sense to bflat. image

You need to configure your project to dump the intermediate outputs of the csproj somewhere else if you want a dual setup like that

Setting the BaseIntermediateOutputPath property in the csproj should achieve that. It defaults to csprojdirectory\obj but placing junk cs files doesn't help. Alternatively, <GenerateAssemblyInfo>false</GenerateAssemblyInfo> should also get rid of the AssemblyInfo file. Or just put the csproj itself somewhere else.