Missing Icon on VS Start Page #655

2percentsilk · 2016-10-28T17:59:55Z

Hello! Please read the contributing guidelines before submitting an issue.

GitHub Extension version: 2.0.15.1
Visual Studio version: VS15 Preview 5

What happened (with steps, logs and screenshots, if possible)
On the Start Page, GitHub shows up correctly in the Open section but the icon is missing. The icon had previously shown up.

2percentsilk · 2016-10-28T18:32:15Z

This is only happening on the first run after installing the extension. I just restarted VS and the icon showed up.

shana · 2016-11-08T20:28:05Z

@abuchholtzau I'd love to know why this is happening, actually. The image is coming from the image service (https://github.com/github/VisualStudio/search?utf8=%E2%9C%93&q=27841f47 and https://github.com/editor-tools/StartPage/blob/master/preview5/StartPagePackage.cs#L26), I have no clue why it wouldn't work the first time (VS registering something late?)

@prasethu @AArnott @clboles Do you know why this would be happening?

AArnott · 2016-11-12T05:30:18Z

I've asked Andrew Sarratori to help out if he can.

Newrad0603 · 2016-11-14T23:09:20Z

I did some debugging after repro-ing the issue. The reason this fails is because at the time the image would be displayed, the GitHub.UI.dll has not been loaded into the app domain, so when the ImageLibrary attempts to load the image, it fails. Toggling the theme a short time after launch causes the image to display. There seems to be a timing issue where sometimes the UI dll is loaded in time, so the image request succeeds. It appears a change needs to be made to make sure that the UI dll is loaded when the new Start Page is instantiated.

shana · 2016-11-14T23:14:15Z

@Newrad0603 Thank you for tracking this down! This makes sense, we'll see how we can fix it.

AArnott · 2016-11-14T23:23:08Z

@Newrad0603: is this a case of a missing codebase path for their github.ui.dll assembly? Is the image service willing to load the assembly as long as the CLR can find it?

Newrad0603 · 2016-11-14T23:26:06Z

@AArnott Yes, the Image Service should load any dll that VS can find. A few other people have hit codebase issue, so I imagine that the missing codebase entry would likely be the cause.

shana · 2016-11-15T20:26:54Z

@AArnott @Newrad0603 What is this codebase path issue? How can we fix it? Is adding a reference to the dll in the package that needs the icon enough to get it to load early enough, or is there something else we're missing?

AArnott · 2016-11-16T05:56:24Z

@shana: Codebase paths are a way you can help the CLR find the path to an assembly from a given full name. It's added to the .exe.config file, alongside binding redirects. The VS install directory is so huge, that not all directories can be in the probing path. So any directories that aren't (most aren't) won't be searched for assemblies unless you either get lucky (there are a few ways this can happen) or you provide a codebase path.
Since in VS you can't just edit the devenv.exe.config file, your pkgdef can contain registration for it, and then VS takes care of it automatically. But rather than writing your own pkgdef entry, if you're using the VS SDK and leveraging pkgdef generation from attributes, you can use the ProvideCodeBaseAttribute to do this.
This way, I think the VS image service will be able to load your assembly when it is creating its image cache.

We recommend you have codebase path entries for all your assemblies so that you never have to rely on luck for the CLR to find your assemblies.

shana · 2016-11-16T10:06:17Z

Since in VS you can't just edit the devenv.exe.config file, your pkgdef can contain registration for it, and then VS takes care of it automatically. But rather than writing your own pkgdef entry, if you're using the VS SDK and leveraging pkgdef generation from attributes, you can use the ProvideCodeBaseAttribute to do this.

This sounds like it would have been the better solution to the problem we've had from the start, where the xaml engine can't find resource dictionary assemblies when loading UI very early in the VS startup cycle, and we had to add a assembly resolver to point VS to the right place.

We recommend you have codebase path entries for all your assemblies so that you never have to rely on luck for the CLR to find your assemblies.

Is this recommendation somewhere? Feels like it should be something mentioned in a "how to do an extension" up front, perhaps even a part of the sample templates, it's such a constant (and subtle) problem.

AArnott · 2016-11-19T03:34:00Z

we had to add a assembly resolver to point VS to the right place.

Oh yes, please remove that.

Is this recommendation somewhere? Feels like it should be something mentioned in a "how to do an extension" up front, perhaps even a part of the sample templates, it's such a constant (and subtle) problem.

It should be. But I haven't seen it. @AlexEyler may know.

AArnott · 2016-11-19T03:35:24Z

By the way, on the image service fail on first load issue, we have the exact same problem with another one of our internal extensions. We tried to solve it with the same provide code base paths solution and it did not solve the problem. So we're still working through it and we'll share what we learned when we solve that. But the provided code base paths technique is still a good one to use regardless.

AlexEyler · 2016-11-19T06:09:03Z

I haven't seen any docs on ProvideCodeBase as well, though there should be some. I'll share with the team on Monday and see if we can get somebody on it.

shana · 2016-11-21T10:09:41Z

We'll put a hold on this fix for now then; all the work we had to do for the RC is currently on a non-mergeable release branch and we need to forward port it to master before we do any major changes to the codebase.

Also, the fact that we can't do builds in VS2015 that target 2017 means that our entire CI and release infrastructure is currently broken, and we can't afford do major work until we get that fixed and back online. I'm not sure when it's going to be possible for 2015 to build for 2017 officially (I'm assuming that it's going to be!), so our priority right now is getting all that back online.

Let us know when you have results on your research!

AArnott · 2016-11-26T04:38:00Z

My team builds our VS2017 features entirely on VS2015 machines. Why do you say that's not yet supported? We use nuget for all our dependencies.

shana · 2016-11-26T17:11:05Z

@AArnott Last time I looked, building extensions with the new vsixv3 format is not supported in 2015. Has that changed?

AArnott · 2016-11-26T20:14:23Z

Just install this nuget package and you'll be building VSIXv3's.

shana · 2016-11-26T22:40:22Z

Ah, yes, we're using that now that RC is out and we've had a breather to fix things, but it doesn't work very well, we had to make changes to the targets file to get it to work with VS2015 for us. It also doesn't play well with packages that generate code at build time (different msbuild versions and all). Nothing about 2017 has been a simple drop-in replacement, with the added problem of making sure nothing we do for the RC breaks VS2015, since we ship one extension for 2015+. Now we're getting CI back working and getting all the required 2017 changes back on master and then we can continue fixing these issues.

AArnott · 2016-11-27T03:43:21Z

Curious. Well please do let us know if you find bugs in the VS SDK BuildTools (or anything else, really). It worked as a drop in replacement for our own uses. And although my team doesn't build VSIXs that work in VS2015 and VS2017, I know the VS SDK team's goal is for VSIXes built with the new SDK to still work in VS2015.

grokys · 2016-11-28T10:11:35Z

Hi @AArnott, I've listed the problems with using Microsoft.VSSDK.BuildTools 15 with VS2015 below:

When you install it on our GitHub.VisualStudio project (which is used on both VS2015 and VS2017 it gives the following error:

2>D:\projects\VisualStudio\packages\Microsoft.VSSDK.BuildTools.15.0.25914-RC2\tools\VSSDK\Microsoft.VsSDK.targets(602,5): error MSB4018: The "GetExtensionsPath" task failed unexpectedly.
2>D:\projects\VisualStudio\packages\Microsoft.VSSDK.BuildTools.15.0.25914-RC2\tools\VSSDK\Microsoft.VsSDK.targets(602,5): error MSB4018: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.VisualStudio.Settings.15.0, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
2>D:\projects\VisualStudio\packages\Microsoft.VSSDK.BuildTools.15.0.25914-RC2\tools\VSSDK\Microsoft.VsSDK.targets(602,5): error MSB4018: File name: 'Microsoft.VisualStudio.Settings.15.0, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
2>D:\projects\VisualStudio\packages\Microsoft.VSSDK.BuildTools.15.0.25914-RC2\tools\VSSDK\Microsoft.VsSDK.targets(602,5): error MSB4018:    at Microsoft.VsSDK.Build.Tasks.GetExtensionsPath.Execute()
2>D:\projects\VisualStudio\packages\Microsoft.VSSDK.BuildTools.15.0.25914-RC2\tools\VSSDK\Microsoft.VsSDK.targets(602,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
2>D:\projects\VisualStudio\packages\Microsoft.VSSDK.BuildTools.15.0.25914-RC2\tools\VSSDK\Microsoft.VsSDK.targets(602,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()

If I try to install the Microsoft.VisualStudio.Settings.15 to our 2017-specific project the package fails to install with:

Attempting to gather dependency information for package 'Microsoft.VisualStudio.Settings.15.0.15.0.25824-RC' with respect to project 'Subpackages\GitHub.StartPage.Preview5', targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 5.53 sec
An item with the same key has already been added.

Using the -IgnoreDependencies switch to InstallPackage allows the NuGet package to install. After this, the build fails with:

D:\projects\VisualStudio\packages\Microsoft.VSSDK.BuildTools.15.0.25901-RC\tools\VSSDK\Microsoft.VsSDK.targets(73,5): warning VSSDK1018: Targets version (15.0.25901.2) and build task version (15.0.25914.7) do not match.  Restarting Visual Studio could help fix this issue.

Restarting Visual Studio did not help fix the issue, in fact it seems to now have reverted to Could not load file or assembly 'Microsoft.VisualStudio.Settings.15.0. We have also seen in our attempts to fix this:

Targets version (15.0.25901.2) and build task version (15.0.25901.2) do not match.

Hope that helps!

AArnott · 2016-12-03T21:26:16Z

@grokys what version of the SDK build tools package did you install? Can you try the latest version? One was published just a few days ago.

2percentsilk · 2017-01-23T18:50:20Z

It seems this is still an issue on most recent builds. Has any progress been made/do we know when the icon fix might be introduced? Thanks!

AArnott · 2017-01-23T19:14:18Z

I don't think we know any more than we did. And IIRC there is another extension with a very similar problem. We probably need to follow up with @artl93's team to figure out what's going on with the image service.

grokys · 2017-02-15T14:04:26Z

I've not seen this for a while so assuming it was fixed in one of the recent VS2017 RCs.

jcansdale · 2017-02-15T16:00:23Z

The icon is consistently missing when I open Visual Studio 2017 Enterprise RC, but for some reason not when I open Visual Studio 2017 community RC.

Strangely it did work a few times with Enterprise when I had the Team Explorer window open at start up. It's stopped working at all now, even when Team Explorer opens with Visual Studio.

It does however always seem to appear if I re-open the Start Page (not that anyone will ever do that).

Some kind of race condition maybe?

2percentsilk · 2017-02-15T19:55:37Z

@Newrad0603 do we have any idea what's going on here? @AArnott mentioned something on the image service so wanted to follow up to see if there were any changes you guys made recently to fix this issue or if we need to start a conversation with Art.

Newrad0603 · 2017-02-16T01:51:56Z

@abuchholtzau @shana

The issue here is the lack of codebase entry for the GitHub.UI.dll. Since VS cannot find it when the Image Service needs it, the image cannot be rendered. Some other mechanism seems to cause the dll to be loaded (likely package load) and that's why the issue can be intermittent depending on when/if the package is loaded prior to rendering the image on the Start Page.

To fix this issue, you can add this to your GitHub.VisualStudio.pkgdef:
[$RootKey$\RuntimeConfiguration\dependentAssembly\codeBase{89C0B89A-7EE9-4A6C-B7E2-4EFE78AD3B1C}]
"name"="GitHub.UI"
"codeBase"="$PackageFolder$\GitHub.UI.dll"
"publicKeyToken"="bc1bd09f2901c82e"
"culture"="neutral"
"version"="2.1.1.4"

Ideally you'd use the ProvideCodeBase attribute to get this created if you have the build dynamically generate your pkgdefs. If you have static pkgdefs, you can just paste the above into it and reploy the updated package. I would recommend tokenizing the version though if you go the 2nd route to make sure you don't get version mismatches.

jcansdale · 2017-02-16T11:15:49Z

@Newrad0603,

Thanks for the suggestion.

I've tried the following, but unfortunately the image is still coming up blank:

Install the latest GitHub Extension for Visual Studio.
This issue is reproducible with VS 2017 Enterprise RC4, so my Extensions folder is here:
\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions
Find the GitHub.VisualStudio.pkgdef file and add the following to the end:

[$RootKey$\RuntimeConfiguration\dependentAssembly\codeBase\{89C0B89A-7EE9-4A6C-B7E2-4EFE78AD3B1C}]
"name"="GitHub.UI"
"codeBase"="$PackageFolder$\GitHub.UI.dll"
"publicKeyToken"="bc1bd09f2901c82e"
"culture"="neutral"
"version"="2.2.0.6"

(note I've added a \ after codeBase and changed the version to 2.2.0.6 compared to your example)
4. Modify the extensions.configurationchanged file.
5. Launch VS 2017 Enterprise RC4.
6. Alas the image is still blank.

Any idea what I might be doing wrong?

BTW, while I've been working on this I've kept running into this issue #864. It doesn't do it every single time when trying to (re)install the extension, but it does it often enough to be really annoying (maybe every 3rd time or so).

AArnott · 2017-02-16T17:23:35Z

@jcansdale Are you sure you got the version right in your pkgdef? That should be the assembly version of the DLL rather than the extension or assembly file version. Usually assembly versions are not exactly matched to the extension version, which is why I ask.

AArnott · 2017-02-16T17:29:13Z

It looks like you got the version right.

Newrad0603 · 2017-02-16T17:45:23Z

@jcansdale Did you make sure your codebase entry actually showed up in the merge devenv.exe config in:
%localappdata%\Microsoft\VisualStudio\15.0_[instanceid]\devenv.exe.config

Newrad0603 · 2017-02-16T18:11:44Z

@jcansdale So it turns out I must have hit the timing issue at the same time I partially fixed the problem. After more digging it turns out that a 2nd dll couldn't be found, so it also needs a codebase. Add this and hopefully it should fix the problem. After adding the below I relaunched VS about a dozen times and the icon always appeared, so fingers crossed :)

[$RootKey$\RuntimeConfiguration\dependentAssembly\codeBase\{588BDF50-8097-49EA-8C5E-7FA966BA6929}]
"name"="GitHub.Exports"
"codeBase"="$PackageFolder$\GitHub.Exports.dll"
"publicKeyToken"="bc1bd09f2901c82e"
"culture"="neutral"
"version"="2.2.0.6"

jcansdale · 2017-02-16T20:40:08Z

@Newrad0603, @AArnott,

Thank you very much for looking into this. I'll try it after dinner and get back to you!

I've been doing a lot of uninstalling and reinstalling our extension on Visual Studio 2017 RC4. Because we don't have it building yet on VS 2017, I'm having to use vsixinstaller.exe. Unfortunately my installation keeps getting into a messed up state and refuses to uninstall. 😭

Do you have any idea what might be causing the following exception?

System.InvalidOperationException: Uninstall of GitHub Extension for Visual Studio failed. To uninstall this extension please uninstall all of the following components:
   at Microsoft.VisualStudio.ExtensionManager.ExtensionEngineImpl.PerformSetupEngineUnInstall(IInstalledExtension extension)
   at Microsoft.VisualStudio.ExtensionManager.ExtensionEngineImpl.UninstallInternal(IInstalledExtension extension, Boolean forceDelete, Version targetedVSVersion)
   at Microsoft.VisualStudio.ExtensionManager.ExtensionEngineImpl.Uninstall(IInstalledExtension extension, Version targetedVSVersion)
   at Microsoft.VisualStudio.ExtensionManager.ExtensionManagerService.Uninstall(IInstalledExtension extension)

I've also had a strange situation where a different (earlier) version of the .pkgdef file ends up getting installed than the one in the .vsix I've asked it to install. Does the contents of the .vsix get cached anywhere? I'm a bit lost as to why this might be happening. 😕

Thanks for any suggestions. It really has been driving me crazy!

Newrad0603 · 2017-02-16T21:16:30Z

@jcansdale I remember there being an issue when attempting to install extensions that were also authored into the install graph, but I don't recall if it's been fixed. The only real way I know of to get rid of the error is to get the state back to what the installer expects. The other option is essentially a sledgehammer and is to delete the install's folder under Program Files\Microsoft VisualStudio\2017 and remove the instance registration from ProgramData\Microsoft\VisualStudio\Packages_Instances. That'll effectively render that instance as non-existent and you should be able to install fresh.

jcansdale · 2017-02-16T23:39:48Z

@Newrad0603,

I ended up going with the nuke it from orbit option! Unfortunately it becomes screwy very quickly.

I did this:

Delete Program Files\Microsoft VisualStudio\2017
Delete ProgramData\Microsoft\VisualStudio\Packages_Instances
Installed VS 2017 Enterprise RC4
Launch VS
Install GitHub for Visual Studio via Extensions and Updates
Relaunched VS
Uninstalled GitHub for Visual Studio
Installed local build of extension with new version
The version installed via Extensions and Updates has mysteriously restored itself! Hu?

I'm really struggling to test new builds!

Should I avoid vsixinstaller.exe completely and simply drop new builds into the Common7\IDE\Extensions directory and bump extensions.configurationchanged?
I'm worried our users will run into this hard to fix/diagnose issue!

Newrad0603 · 2017-02-17T00:20:24Z

@jcansdale I am not 100% on the extensions part since I have mostly been working in the installer side. My understanding is your scenario is similar to one our SDK team has. The idea is that the extension is chained into the installer and initially installed via that mechanism. Then updates can be pushed to the extension like they were in the past so you can update them via the Ext. & Updates UI and it will do the right thing in terms of maintaining the state. I believe things only go sideways in terms of manually invoking the vsix installer. All that being said, it'd be better to talk with our extensibility team since they handle the vsix installer and how it behaves with our installation mechanisms.

tinaschrepfer · 2017-02-21T21:53:39Z

@jcansdale You should be able to install/upgrade GitHub from VSIXInstaller or from Willow. I tried the following scenario and it all worked as expected for me:

Install VS 2017 with GitHub from VS Installer, update to the latest version on the marketplace, uninstall VS.
Install VS 2017, install GitHub from the marketplace, uninstall VS.

What are you seeing specifically that's failing with respect to extensions?

jcansdale · 2017-02-21T23:58:31Z

Hi @tinaschrepfer,

Thanks for getting in touch!

There are two scenarios we're having difficulty with:

Users should be able to automatically update the extension
We need to install a standalone VSIX file when testing new version.

I've managed to find a workaround for 2, but 1 is by far the most serious. If automatic updates work for most 3rd party extensions, but not ours, the vast majority of users won't bother investigating and updating manually. 😢

I've put a description and repro in a separate issue. Could you have a look at let me know if there is any way we can get this scenario working? #877

tinaschrepfer · 2017-02-22T00:12:56Z

@jcansdale I replied on the issue directly. Please see there for more info.

paladique · 2017-02-27T18:24:35Z

Fixed in #875

paladique added bug cosmetic labels Nov 4, 2016

shana mentioned this issue Nov 15, 2016

Fix remote container provider id editor-tools/StartPage#1

Merged

ericnewton76 mentioned this issue Dec 17, 2016

Missing stack trace when exception occurs during OneTimeSetUp nunit/nunit3-vs-adapter#284

Closed

paladique mentioned this issue Feb 3, 2017

Octokat Image/Logo Missing on Welcome Page #533

Closed

grokys closed this as completed Feb 15, 2017

jcansdale reopened this Feb 15, 2017

jcansdale self-assigned this Feb 16, 2017

jcansdale mentioned this issue Feb 21, 2017

Fix assembly resolving issues and start page icon #875

Merged

paladique closed this as completed Feb 27, 2017

Newrad0603 mentioned this issue Sep 21, 2017

bindingRedirects can become out of sync with installed extension #1217

Closed

OsirisTerje mentioned this issue Oct 2, 2017

Missing stack trace when exception occurs during OneTimeSetUp nunit/nunit#2466

Closed

Missing Icon on VS Start Page #655

Missing Icon on VS Start Page #655

Comments

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!