Updating from official/gallery build to beta releases #1063

dasMulli · 2016-12-20T23:43:14Z

Both @itlackey and me ran into an issue updating from the 1.5.3 version to the 1.6.0-beta6 version from GitHub on a Mac (OS X 10.12, VSCode version 1.8.0).
It seems that the old and new extensions were installed side-by-side and the old one would load instead of the new one.

code --list-extensions would show only ms-vscode.csharp installed.
Executing ode --uninstall-extension ms-vscode.csharp once succeeded but code --list-extensions still showed the extension being installed. Executing the uninstall command a second time removed the extension for good (not listed anymore). Then installing the .vsix again using code --install-extension fixed the issue, leaving only the newest beta6 version installed which successfully loaded.

I'm not sure if this is a packaging issue or a VSCode bug.. cc @DustinCampbell

The issue manifests itself in seeing the error message The target "ResolveReferences" does not exist in the project. even though all the newest bits seem to be installed.
This was probably also observed by @mcmonkey4eva on https://github.com/dotnet/cli/issues/4999.

The text was updated successfully, but these errors were encountered:

DustinCampbell · 2016-12-20T23:50:41Z

Hi @dasMulli. I've seen this before as well. I suspect it's actually a VS Code bug, though I haven't dug too deeply to understand why it happens.. However, this is why our instructions specify to remove the extension fully in the UI for beta releases.

dasMulli · 2016-12-21T00:00:22Z

Good thing it is documented 👍
Bad thing: I suspect that a lot of ppl (like me) will not look through that wiki before installing betas..

I suspect that this may hit more people, especially since the betas are the only way to work on a project in vs2017 and vscode. (thanks for updating so quickly!)
Maybe including a line like "IMPORTANT: See instructions for (safely) installing beta releases" in the release notes, linking to the wiki page, could be helpful?

DustinCampbell · 2016-12-21T00:12:49Z

Agreed. I didn't mean to imply that the wiki article is enough; just that I'd run into it before and ended up writing the article that way.

@jrieken: Do you know if this is a known issue with VS Code? I have a sneaking suspicion the problem is specifically with extension version containing a pre-release or beta label.

itlackey · 2016-12-21T02:07:20Z

Just an update. I followed the steps in the wiki and now have a different issue... or at least a different error. ;)

Below is the complete log, hopefully it helps. If not, I will remove this comment (and post it elsewhere if that is a better option).

 Starting OmniSharp server at 12/20/2016, 7:58:33 PM
    Target: /Volumes/C 1/Users/itlackey/Repos/Digital Inventory Program/DIPDemo/NewDemo

OmniSharp server started wth Mono
    Path: /Users/itlackey/.vscode/extensions/ms-vscode.csharp-1.6.0-beta6/bin/run
    PID: 41651

OmniSharp: -s /Volumes/C 1/Users/itlackey/Repos/Digital Inventory Program/DIPDemo/NewDemo --hostPID 41617 --stdio DotNet:enablePackageRestore=false --encoding utf-8
{"Event":"log","Body":{"LogLevel":"INFORMATION","Name":"OmniSharp.Startup","Message":"Omnisharp server running using Stdio at location '/Volumes/C 1/Users/itlackey/Repos/Digital Inventory Program/DIPDemo/NewDemo' on host 41617."},"Seq":1,"Type":"event"}
[INFORMATION:OmniSharp.DotNet.DotNetProjectSystem] Initializing in /Volumes/C 1/Users/itlackey/Repos/Digital Inventory Program/DIPDemo/NewDemo
[INFORMATION:OmniSharp.DotNet.DotNetProjectSystem] Auto package restore: False
[INFORMATION:OmniSharp.DotNet.DotNetProjectSystem] Update workspace context
[INFORMATION:OmniSharp.DotNet.DotNetProjectSystem] Resolving projects references
[INFORMATION:OmniSharp#MSBuild] MSBUILD_EXE_PATH environment variable set to /Users/itlackey/.vscode/extensions/ms-vscode.csharp-1.6.0-beta6/bin/omnisharp/msbuild/MSBuild.dll
[INFORMATION:OmniSharp#MSBuild] MSBuildExtensionsPath environment variable set to /Users/itlackey/.vscode/extensions/ms-vscode.csharp-1.6.0-beta6/bin/omnisharp/msbuild
[INFORMATION:OmniSharp#MSBuild] MSBuildSDKsPath environment variable set to /Users/itlackey/.vscode/extensions/ms-vscode.csharp-1.6.0-beta6/bin/omnisharp/msbuild/Sdks
[INFORMATION:OmniSharp#MSBuild] No solution files found in '/Volumes/C 1/Users/itlackey/Repos/Digital Inventory Program/DIPDemo/NewDemo'
[WARNING:OmniSharp#ProjectFileInfo] Couldn't locate Mono, TargetFrameworkRootPath not specified
[INFORMATION:OmniSharp#MSBuild] Add project: /Volumes/C 1/Users/itlackey/Repos/Digital Inventory Program/DIPDemo/NewDemo/DIP.csproj
[INFORMATION:OmniSharp#MSBuild] Update project: DIP
[INFORMATION:OmniSharp.Script.ScriptProjectSystem] Detecting CSX files in '/Volumes/C 1/Users/itlackey/Repos/Digital Inventory Program/DIPDemo/NewDemo'.
[INFORMATION:OmniSharp.Script.ScriptProjectSystem] Could not find any CSX files
[INFORMATION:OmniSharp.Startup] Configuration finished.
[ERROR:Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware] An unhandled exception has occurred: Object reference not set to an instance of an object
[INFORMATION:OmniSharp.Middleware.LoggingMiddleware] /currentfilemembersastree: 500 628ms

My noob, guess is it appears to not be correctly importing the SDK targets. In the editor I get red squiggles all over with messages like "Predefined type System.Object is not defined or imported" but I am really just hacking and slashing at this point.

DustinCampbell · 2016-12-21T02:10:14Z

It looks mostly ok except for this bit:

[ERROR:Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware] An unhandled exception has occurred: Object reference not set to an instance of an object
[INFORMATION:OmniSharp.Middleware.LoggingMiddleware] /currentfilemembersastree: 500 628ms

Is this error manifesting in some way in VS Code?

itlackey · 2016-12-21T02:12:44Z

Most noticeable are the red squiggles so far. Also, if you use the integrated terminal and try dotnet build I get the "Couldn't find project.json in current directory" message.

FYI here is the bash dotnet version output:

bash-3.2$ dotnet --version
1.0.0-preview2-1-003177

Should Omnisharp be using the new preview?

DustinCampbell · 2016-12-21T02:14:39Z

Run dotnet --info and let me know what version you have.

DustinCampbell · 2016-12-21T02:15:14Z

And, to be clear, you're trying to open a newer .NET Core C# project in VS Code on a Unix-based system, correct?

itlackey · 2016-12-21T02:15:25Z

bash-3.2$ dotnet --info
.NET Command Line Tools (1.0.0-preview2-1-003177)

Product Information:
 Version:            1.0.0-preview2-1-003177
 Commit SHA-1 hash:  a2df9c2576

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64

DustinCampbell · 2016-12-21T02:15:30Z

newer = csproj-based .NET Core.

DustinCampbell · 2016-12-21T02:15:46Z

That version of the .NET CLI only supports project.json-based .NET Core projects.

itlackey · 2016-12-21T02:16:02Z

yes, sorry. back story == teammate loaded vs2017 and created this project. i am trying to run it on my mac with vscode

DustinCampbell · 2016-12-21T02:16:21Z

Got it. Grab a newer .NET CLI from https://dot.net.

DustinCampbell · 2016-12-21T02:17:21Z

Here's a better link: https://www.microsoft.com/net/download/core#/current

Grab the OSX .NET Core SDK release from there

itlackey · 2016-12-21T02:17:31Z

right, i was under the impression OmniSharp would use a "local" copy of the newer CLI "side-by-side" with the global "stable" cli install. Am I simply mistaken there and need to install the preview CLI globally?

DustinCampbell · 2016-12-21T02:18:23Z

not precisely. OmniSharp doesn't include a full version of the CLI. dotnet build still shells out to the global one.

DustinCampbell · 2016-12-21T02:19:26Z

So, it's likely that the errors will go away if you install a newer .NET Core SDK and run dotnet restore on your project. Then, open the project again in VS Code.

itlackey · 2016-12-21T02:19:38Z

ahh ok i see. so would the "Current SDK" be the new msbuild tooling version? i thought that was all still "preview"

DustinCampbell · 2016-12-21T02:20:07Z

For the CLI, it's all preview (including LTS).

DustinCampbell · 2016-12-21T02:20:46Z

And, if you have a project created in VS 2017, that's definitely preview as well since VS 2017 RC is all that's out.

DustinCampbell · 2016-12-21T02:21:09Z

plus, you have beta6 of the C# extension in VS Code installed.

You're just swimming in preview. 😄

itlackey · 2016-12-21T02:21:53Z

Got it. Downloading now. Thanks for the help!

Will post the results in a bit.

And, if you have a project created in VS 2017, that's definitely preview as well since VS 2017 RC is all that's out.

Exactly why I am trying to get it going on the Mac so I don't blow up my VM where I do my real work ;P

DustinCampbell · 2016-12-21T02:25:09Z

Exactly why I am trying to get it going on the Mac so I don't blow up my VM where I do my real work ;P

Make sense.

itlackey · 2016-12-21T02:46:49Z

I got the same result after installing the Current x64 SDK for Mac

dotnet --info
.NET Command Line Tools (1.0.0-preview2-1-003177)

Product Information:
 Version:            1.0.0-preview2-1-003177
 Commit SHA-1 hash:  a2df9c2576

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64

Ugh.

Is this where I should be downloading the SDK instead?
https://github.com/dotnet/core/blob/master/release-notes/preview4-download.md

DustinCampbell · 2016-12-21T02:50:48Z

Sorry. That's my bad. That is the latest for Current. The CLI build that is included in the latest VS 2017 RC is newer than that. Try the CLI at this link. That's the latest from the front page of the https://github.com/dotnet/cli repo.

Sorry for your trouble.

itlackey · 2016-12-21T02:53:43Z

No worries. There is so much of this stuff to weed through I am not sure how anyone keeps it straight.

DustinCampbell · 2016-12-21T02:56:35Z

Well, clearly, I'm not keeping it straight. 😄

FWIW, we're definitely hearing the feedback on the complexity of the whole .NET Core system and working on that. Sorry about the current state of affairs.

itlackey · 2016-12-21T03:08:42Z

Seriously, no worries... we are all devs here ;)

I think I got it.

Grabbed the x64 installer from here: https://github.com/dotnet/core/blob/master/release-notes/preview4-download.md
Restarted terminal
Ran dotnet restore
Ran dotnet build
Opened VSCode

It appears to be working now. 🎉

I really appreciate the help. You and @dasMulli have been a huge help!! ( @dasMulli spent a lot of time bringing some clarity to the entire project.json to .csproj reasoning etc. )

BTW: I have been a long time web dev. Almost entirely .net focused (after moving ASP Classic). I don't feel like .Net core is complex. I actually feel it is a return to the roots. .Net had become to move tooling and not enough "I can fix that in notepad if it breaks." Anything that can be done to keep core "pure" and not open is great IMO.

jrieken · 2016-12-21T08:09:54Z

re #1063 (comment) - @joaomoreno should know. Sounds like a bug tho

joaomoreno · 2017-01-03T08:33:16Z

When installing a VSIX, VS Code never matches it against any extension installed via the gallery. Both will be installed side-by-side.

DustinCampbell · 2017-01-03T14:04:37Z

@joaomoreno: Is that the intended behavior or a bug? If someone has the C# extension installed via the gallery and then installs a VSIX of a beta version, they have both extensions "installed". However, only one appears on the extension pane in VS Code while the other gets loaded. How is a user to diagnose this? How is it helpful to the user to have them side by side?

joaomoreno · 2017-01-03T14:57:09Z

It has been intended behaviour so far. Here's the issue to upvote/follow: microsoft/vscode#15756. Distributing it as a VSIX is not ideal and was never intended as a "pre-release" mechanism.

gregg-miskelly · 2017-01-03T17:24:34Z

@joaomoreno the one scenario that that doesn't address is if you want to send privates to one user to try out. For example, to add extra logging to diagnose an issue they are running into, or test a fix. So while I definitely agree that an official beta channel would be nice, it isn't the right answer 100% of the time. So if it isn't too hard, it might be worth the work to also block SxS extensions with the same identity but different versions. Even if it just gives the user an error that would be nice.

DustinCampbell · 2017-02-01T03:27:03Z

Just catching up here.

@joaomoreno: When a VSIX version of an extension (with a newer version) is installed side-by-side with the same extension (i.e. the same id), is it the intended design that the newer version appears on the Extensions pane but the older version is what gets loaded? I can't imagine that being a useful experience.

joaomoreno · 2017-02-01T09:35:29Z

@DustinCampbell It's just not implemented. The current behaviour is unspecified.

I'll make sure we get this fixed asap.

Actually, the issues to follow are microsoft/vscode#17290 and microsoft/vscode#19259

DustinCampbell · 2017-02-01T16:27:29Z

Thanks @joaomoreno! And to be clear, I think we are interested in a beta channel for extensions. However, as @gregg-miskelly mentioned, this is kind of a different scenario.

dasMulli · 2017-02-01T17:37:47Z

Thanks @joaomoreno for clarifying, closing this in favour of the mentioned vscode issues.

dasMulli closed this as completed Feb 1, 2017

DustinCampbell mentioned this issue Feb 3, 2017

'dotnet: Restore Packages' VS Code command does not work #1175

Closed

Updating from official/gallery build to beta releases #1063

Updating from official/gallery build to beta releases #1063

Comments

dasMulli commented Dec 20, 2016

DustinCampbell commented Dec 20, 2016

dasMulli commented Dec 21, 2016 • edited Loading

DustinCampbell commented Dec 21, 2016

itlackey commented Dec 21, 2016 • edited Loading

DustinCampbell commented Dec 21, 2016

itlackey commented Dec 21, 2016 • edited Loading

DustinCampbell commented Dec 21, 2016

DustinCampbell commented Dec 21, 2016

itlackey commented Dec 21, 2016

DustinCampbell commented Dec 21, 2016

DustinCampbell commented Dec 21, 2016

itlackey commented Dec 21, 2016

DustinCampbell commented Dec 21, 2016

DustinCampbell commented Dec 21, 2016

itlackey commented Dec 21, 2016

DustinCampbell commented Dec 21, 2016

DustinCampbell commented Dec 21, 2016

itlackey commented Dec 21, 2016

DustinCampbell commented Dec 21, 2016

DustinCampbell commented Dec 21, 2016

DustinCampbell commented Dec 21, 2016

itlackey commented Dec 21, 2016

DustinCampbell commented Dec 21, 2016

itlackey commented Dec 21, 2016 • edited Loading

DustinCampbell commented Dec 21, 2016

itlackey commented Dec 21, 2016

DustinCampbell commented Dec 21, 2016

itlackey commented Dec 21, 2016

jrieken commented Dec 21, 2016

joaomoreno commented Jan 3, 2017 • edited Loading

DustinCampbell commented Jan 3, 2017

joaomoreno commented Jan 3, 2017

gregg-miskelly commented Jan 3, 2017

DustinCampbell commented Feb 1, 2017

joaomoreno commented Feb 1, 2017 • edited Loading

DustinCampbell commented Feb 1, 2017

dasMulli commented Feb 1, 2017

dasMulli commented Dec 21, 2016 •

edited

Loading

itlackey commented Dec 21, 2016 •

edited

Loading

itlackey commented Dec 21, 2016 •

edited

Loading

itlackey commented Dec 21, 2016 •

edited

Loading

joaomoreno commented Jan 3, 2017 •

edited

Loading

joaomoreno commented Feb 1, 2017 •

edited

Loading