-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gitversion task and vscode omnisharp using .NET Core SDK 2.1.500 #35
Comments
Thanks for opening issue! First question that pops into my mind: did you do command build using Do you have any small repro project that I can download and use to test? I also have Windows machine so I could do the testing relatively easily. :) |
No problem! So I did I'll see if I can build you a small repro, will get back to you on that. |
Here you go - easy to minimally reproduce. Just did a plain
|
The reason why I thought this would be .NET Desktop-related is because of this error line: I guess this leaves us with the following questions:
The detection on which assembly to load works like this currently (taken from
So the presence of magical What is even more weird is that the Furthermore, when I build with command line using .NET Desktop MSBuild (like this: I peeked into OmniSharp directory ( I will investigate if a I could fix this by loading .NET Core version of UtilPack DLL within OmniSharp, or by adding binding redirect in a |
Update: loading the the .NET Core version of UtilPack DLL by OmniSharp does not work, so I guess either something needs to by done in OmniSharp side (I don't know how they are using the MSBuild in such way that it is causing this different behaviour, and why did they even make their own MSBuild), or hopefully a magical |
Looks like it might be related to OmniSharp/omnisharp-roslyn#1094? |
Just to eliminate it, I have just tried the workaround in that issue - and yet still have a very similar problem (even though it seems to now be selecting the 'omnisharp' msbuild instance instead of my VS one. Same log:
|
Yeah I've tried the There is definetly something weird going on with OmniSharp. I was looking at the OmniSharp folder which contains the OmniSharp.exe, and it kinda looks like it's running on Mono... but I am not sure! I guess it runs stuff in some way different than normal VS MSBuild, or even the old XBuild from Mono. Maybe raise an issue with OmniSharp, and provide the test.zip and say that it builds normally with both dotnet and VS MSBuild, but not with OmniSharp (even when it is using VS MSBuild)? Is there any way to make OmniSharp make use actual |
I'll raise an issue and link to here - will keep you posted. Will ask for some clarity on their roadmap and how closely they're going to bind it to msbuild, but tbh I wouldn't hold your breath on that front. I'm surprised that I'm the first person to have noticed this - of all the people using gitversion I can't be the only one using the basically stock setup of vscode w/syntax highlighting! :) |
@kieranbenton : I haven't forgot about this issue, btw, but I've been tremendously busy with adding a CI pipeline to all of my projects (some of which have stuff like custom IL code generation and CS code generation during their build process). That task is luckily soon done tho. Regarding your usecase - I am not sure if VSCode is that popular among C# developers. Most people use VS, either free Community edition, or paid Professional/Enterprise editions. But I am sure more people will move towards VSCode-based usage scenario, as VSCode has CodeLens (as did VS Community before 2017 version), at least for now. |
Not a problem @stazz - I absolutely apprecitate the help and insight. Just the fact that this involves binding redirects is enough to make me break out in a cold sweat :) In terms of popularity I would say that tides are shifting. I'm a long standing old school .NET framework guy who is trying to update his skills, and certianly anyone new coming to the ecosystem of .NET Core is being pushed down the vscode route. Googling 'getting started with dotnet core" (for me at least) and the 4th entry is "https://docs.microsoft.com/en-us/dotnet/core/tutorials/with-visual-studio-code" and the ones above that are just using the command line. So I'd expect the balance to change ;-) |
Haha, ah yes, the assembly binding redirects are such a curseword on .NET Desktop, I admit that. I'm glad they took other direction in .NET Core. I also have many years of expertise with the .NET Desktop world, and I gotta admit, for everything else than C#, I am using VSCode. So far tho, probably from the sheer amount of experience the VS had with C# and other .NET languages, the classic VS experience is still better for C# stuff (I haven't yet tried F#, and hopefully will never need to try VSBasic :) ). The workflow and the IDE support there is just wonderful. That said, I also expect the balance change. The VSCode is really good IDE frankly, and just the fact it has CodeLens already puts it nicely above many other options. Just some tweaks more to the workflow and other nuances and I probably start using that for C# as well. Btw, I wonder why OmniSharp is not built on top of .NET Core? That would eliminate whole class of bugs like this... :) |
Yeah I find this quite bizarre as well - it must be surely given its x-platform? But redirects... so desktop must be involved at some level?? As much as I'd like to be able to just get gitversion working I'm also intrigued... VSCode is great. As much as I ocassionally miss resharper and a couple of other things in full fat VS (auto panel hiding!) I've pretty much managed to go cold turkey and just live in VsCode world for a while now. That being said I've not actually done a lot of coding lately so will have to see how it goes! How widely is your library used? I've not come across it before. |
I love VSCode for TypeScript experience, there it really shines. Also, I think many C# devs have now been watching how TypeScripts gets a lot of really cool type-related features and improvements, and getting quite envious of that. I have to say the MS has really outdone itself with the TS. I guess my library is not as widely used as I would like it to be. The GitVersionTask is the only usecase I know, and kudos to @dazinator for being patient when we worked together to fix the growing pains (native libraries, various runtimes, mono, etc) of the library. I would say it is in quite good shape now (and actually, it has moved to https://github.com/stazz/NuGetUtils/tree/develop/Source/Code/NuGetUtils.MSBuild.Exec after I decomposed this big repository into several smaller ones). I guess I just don't know any forum/media where OSS guys could advertise their libraries (in meaningful way without it being drowned into a huge mass of all various stuff that is out there). But I certainly would be happier if more people would use my stuff. |
Originally reported here: GitTools/GitVersion#1503
Using gitversion
4.0.1-beta1.50
(I believe which uses2.9.1
?) a command line build works fine on SDK2.1.500
... BUT when using vscode and omnisharp1.32.8
I'm getting failures - meaning that intellisense etc isn't working for me. On windows btw.Exception is:
Any more details just let me know?
The text was updated successfully, but these errors were encountered: