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

Missing Icon on VS Start Page #655

Closed
abuchholtzau opened this Issue Oct 28, 2016 · 40 comments

Comments

Projects
9 participants
@abuchholtzau

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.

github_icon_missing

@abuchholtzau

This comment has been minimized.

Show comment
Hide comment
@abuchholtzau

abuchholtzau Oct 28, 2016

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

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

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

shana Nov 8, 2016

Collaborator

@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?

Collaborator

shana commented Nov 8, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Nov 12, 2016

Collaborator

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

Collaborator

AArnott commented Nov 12, 2016

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

@Newrad0603

This comment has been minimized.

Show comment
Hide comment
@Newrad0603

Newrad0603 Nov 14, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@shana

shana Nov 14, 2016

Collaborator

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

Collaborator

shana commented Nov 14, 2016

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

@AArnott

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Nov 14, 2016

Collaborator

@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?

Collaborator

AArnott commented Nov 14, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@Newrad0603

Newrad0603 Nov 14, 2016

@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.

@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

This comment has been minimized.

Show comment
Hide comment
@shana

shana Nov 15, 2016

Collaborator

@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?

Collaborator

shana commented Nov 15, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Nov 16, 2016

Collaborator

@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.

Collaborator

AArnott commented Nov 16, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@shana

shana Nov 16, 2016

Collaborator

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.

Collaborator

shana commented Nov 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Nov 19, 2016

Collaborator

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.

Collaborator

AArnott commented Nov 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Nov 19, 2016

Collaborator

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.

Collaborator

AArnott commented Nov 19, 2016

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

This comment has been minimized.

Show comment
Hide comment
@AlexEyler

AlexEyler Nov 19, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@shana

shana Nov 21, 2016

Collaborator

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!

Collaborator

shana commented Nov 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Nov 26, 2016

Collaborator

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.

Collaborator

AArnott commented Nov 26, 2016

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

This comment has been minimized.

Show comment
Hide comment
@shana

shana Nov 26, 2016

Collaborator

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

Collaborator

shana commented Nov 26, 2016

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

@AArnott

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Nov 26, 2016

Collaborator

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

Collaborator

AArnott commented Nov 26, 2016

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

@shana

This comment has been minimized.

Show comment
Hide comment
@shana

shana Nov 26, 2016

Collaborator

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.

Collaborator

shana commented Nov 26, 2016

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

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Nov 27, 2016

Collaborator

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.

Collaborator

AArnott commented Nov 27, 2016

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

This comment has been minimized.

Show comment
Hide comment
@grokys

grokys Nov 28, 2016

Contributor

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!

Contributor

grokys commented Nov 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Dec 3, 2016

Collaborator

@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.

Collaborator

AArnott commented Dec 3, 2016

@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.

@abuchholtzau

This comment has been minimized.

Show comment
Hide comment
@abuchholtzau

abuchholtzau Jan 23, 2017

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!

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

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Jan 23, 2017

Collaborator

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.

Collaborator

AArnott commented Jan 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@grokys

grokys Feb 15, 2017

Contributor

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

Contributor

grokys commented Feb 15, 2017

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

@grokys grokys closed this Feb 15, 2017

@jcansdale

This comment has been minimized.

Show comment
Hide comment
@jcansdale

jcansdale Feb 15, 2017

Contributor

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.

image

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?

Contributor

jcansdale commented Feb 15, 2017

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.

image

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?

@jcansdale jcansdale reopened this Feb 15, 2017

@abuchholtzau

This comment has been minimized.

Show comment
Hide comment
@abuchholtzau

abuchholtzau Feb 15, 2017

@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 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

This comment has been minimized.

Show comment
Hide comment
@Newrad0603

Newrad0603 Feb 16, 2017

@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.

@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 jcansdale self-assigned this Feb 16, 2017

@jcansdale

This comment has been minimized.

Show comment
Hide comment
@jcansdale

jcansdale Feb 16, 2017

Contributor

@Newrad0603,

Thanks for the suggestion.

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

  1. Install the latest GitHub Extension for Visual Studio.
  2. 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
  3. 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).

Contributor

jcansdale commented Feb 16, 2017

@Newrad0603,

Thanks for the suggestion.

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

  1. Install the latest GitHub Extension for Visual Studio.
  2. 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
  3. 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).

@grokys grokys added this to Not Started in 2.2.0.8 Feb 16, 2017

@AArnott

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Feb 16, 2017

Collaborator

@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.

Collaborator

AArnott commented Feb 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Feb 16, 2017

Collaborator

It looks like you got the version right.

Collaborator

AArnott commented Feb 16, 2017

It looks like you got the version right.

@Newrad0603

This comment has been minimized.

Show comment
Hide comment
@Newrad0603

Newrad0603 Feb 16, 2017

@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

@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

This comment has been minimized.

Show comment
Hide comment
@Newrad0603

Newrad0603 Feb 16, 2017

@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"

Newrad0603 commented Feb 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@jcansdale

jcansdale Feb 16, 2017

Contributor

@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!

Contributor

jcansdale commented Feb 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@Newrad0603

Newrad0603 Feb 16, 2017

@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.

Newrad0603 commented Feb 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@jcansdale

jcansdale Feb 16, 2017

Contributor

@Newrad0603,

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

I did this:

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

I'm really struggling to test new builds!

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

jcansdale commented Feb 16, 2017

@Newrad0603,

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

I did this:

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

I'm really struggling to test new builds!

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

This comment has been minimized.

Show comment
Hide comment
@Newrad0603

Newrad0603 Feb 17, 2017

@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.

Newrad0603 commented Feb 17, 2017

@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.

@grokys grokys moved this from Not Started to In Progress in 2.2.0.8 Feb 20, 2017

@tinaschrepfer

This comment has been minimized.

Show comment
Hide comment
@tinaschrepfer

tinaschrepfer Feb 21, 2017

Collaborator

@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?

Collaborator

tinaschrepfer commented Feb 21, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@jcansdale

jcansdale Feb 21, 2017

Contributor

Hi @tinaschrepfer,

Thanks for getting in touch!

There are two scenarios we're having difficulty with:

  1. Users should be able to automatically update the extension
  2. 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

Contributor

jcansdale commented Feb 21, 2017

Hi @tinaschrepfer,

Thanks for getting in touch!

There are two scenarios we're having difficulty with:

  1. Users should be able to automatically update the extension
  2. 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

This comment has been minimized.

Show comment
Hide comment
@tinaschrepfer

tinaschrepfer Feb 22, 2017

Collaborator

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

Collaborator

tinaschrepfer commented Feb 22, 2017

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

@paladique

This comment has been minimized.

Show comment
Hide comment
@paladique

paladique Feb 27, 2017

Collaborator

Fixed in #875

Collaborator

paladique commented Feb 27, 2017

Fixed in #875

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment