Fails to launch on 2022 17.2.0 Preview 5.0

[chucker]

From ActivityLog.xml:

SetSite failed for package [BuildVisionPackage]
Source: 'Microsoft.VisualStudio.Validation'
Description: Cannot find an instance of the Microsoft.VisualStudio.Shell.Interop.IVsSolutionBuildManager5 service.

VS otherwise works fine, so particular error is a bit puzzling. Perhaps the extension is loaded too early?

[michael-hawker]

I'm seeing the same (with the same error message) in the latest 17.2.0 stable release.

<entry>
    <record>959</record>
    <time>2022/05/10 22:33:51.518</time>
    <type>Error</type>
    <source>VisualStudio</source>
    <description>SetSite failed for package [BuildVisionPackage]Source: &apos;Microsoft.VisualStudio.Validation&apos; Description: Cannot find an instance of the Microsoft.VisualStudio.Shell.Interop.IVsSolutionBuildManager5 service.&#x000D;&#x000A;</description>
    <guid>{837C3C3B-8382-4839-9C9A-807B758A929F}</guid>
    <hr>80131500</hr>
    <errorinfo></errorinfo>
  </entry>

[StefanKert]

Hi folks,

currently checking this and I'll let you know if there is a fix available :) thanks for reporting

[StefanKert]

So here is a quick update.

It seems like one of the interfaces that is being used in BuildVision for listening to BuildEvents (icrosoft.VisualStudio.Shell.Interop.IVsSolutionBuildManager5) is conflicting somehow with version 17.2.

The interface type that is expected is located in Microsoft.VisualSTudio.Interop assembly, which is the case for most other BuildManagers, but not version 5.

I'll do further checks and keep you posted :)

[GitSparTV]

+1 for this

[PeterJarrettUK]

Annoyingly I've just had the 17.2 update drop onto my pc as it's now full release and comes down via VS Auto Update - and now I've got the same BuildVision fail to load - thanks to you writing such a great extension I'm really missing it now VS has killed it - can't wait for a fix :-) !

But thank you again for a great add in - keep up the great work!

[latenightsurfer]

So here is a quick update.

It seems like one of the interfaces that is being used in BuildVision for listening to BuildEvents (icrosoft.VisualStudio.Shell.Interop.IVsSolutionBuildManager5) is conflicting somehow with version 17.2.

The interface type that is expected is located in Microsoft.VisualSTudio.Interop assembly, which is the case for most other BuildManagers, but not version 5.

I'll do further checks and keep you posted :)

can you estimate when there will be a fix available?

[jzabroski]

can you estimate when there will be a fix available?

@latenightsurfer Can you go fix the issue? These questions aren't helpful and what makes open source software in .NET so bad at times.

[Janek91]

@latenightsurfer any news?

[mitchcapper]

@latenightsurfer any news?

Seriously take a hint. Unless you have something to contribute in terms of technical assistance, technical details, or monetary assistance for the project please do not post unhelpful comments. These sort of comments can be demotivating. One of the contributors has already said they will post when they have updates. SO you want 'news' @Janek91, hit the subscribe button in the upper right of the issue report, you will get notified when there is a meaningful update (or someone else makes a useless comment).

[kenny1983]

@latenightsurfer any news?

Seriously take a hint. Unless you have something to contribute in terms of technical assistance, technical details, or monetary assistance for the project please do not post unhelpful comments. These sort of comments can be demotivating. One of the contributors has already said they will post when they have updates. SO you want 'news' @Janek91, hit the subscribe button in the upper right of the issue report, you will get notified when there is a meaningful update (or someone else makes a useless comment).

Wow...I totally get where you're coming from mate, but geez, that was just a bit harsh don't you think??

[chucker]

@kenny1983 Mitch isn’t the developer, FWIW

[kenny1983]

Yeah I realise that now. Edited my comment accordingly. On Fri, 16 Sept 2022, 9:19 pm Sören Nils Kuklau, @.***> wrote:

@kenny1983 https://github.com/kenny1983 Mitch isn’t the developer, FWIW

— Reply to this email directly, view it on GitHub https://github.com/StefanKert/BuildVision/issues/120#issuecomment-1249241937, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACHCHCQZ5MKZ3T2DILBKTQTV6RJSJANCNFSM5UWGXLBQ . You are receiving this because you were mentioned.Message ID: @.***>

[mitchcapper]

Wow...I totally get where you're coming from mate, but geez, that was just a bit harsh don't you think??

Yes. As subtly generally doesn't seem to work. The developer previously stated

• I'll do further checks and keep you posted :)

• @latenightsurfer then felt asking the developer if they could estimate when it would be fixed was appropriate

• jzabroski then pointed out the fact its open source so if you need it fixed you are welcome to contribute to do so and the fact these questions annoy many developers.

• Then @Janek91 commented another useless comment of essentially whats going on with the fix?

These things to me show either @Janek91 did not read or think through the comments thus far to realize how that is likely to be annoying, or they did and decided hey who cares im going to ask for an update anyway. This is also reinforced as they directed the update request to a user who isn't a contributor on this project. Further, if the dev didn't respond to @latenightsurfer why should you expect them now to answer you?

As clearly jazbroski's comment was either not understood nor not headed it seemed something more blunt was in order. Janek is not new to GH and likely aware how these thing work as well.

All of this is not a new phenomenon to say the least, it happens on most projects and annoys most developers and even when someone has already pointed that out in this very bug report it is ignored and the me first give me an update approach is still taken.

@kenny1983 comes along and mistakenly assuming I was the developer stated:

If you're going to be like that, I'll completely forget about ever supporting this extension. Thanks 👍

or essentially said: Boy how rude you are, I will never even think about supporting this extension in the future. Now I am not sure if that means @kenny1983 has provided support for it in the past, or was about to make some contribution, (or more than likely neither) but lets think about that statement. They were mad as they thought the developer was being rude, however jzabroski tried to point it out in a nicer fashion, no luck. As not the project owner I can make my comment and hopefully these sorts of users will finally get why these actions are potentially so annoying for so many without a lot of backlash on the actual owner.

[michael-hawker]

Looks like this branch was started by the developer to start working on a fix (as they had stated). Not sure what's left for it to be completed. I'm not too familiar with the intricacies of building VS extensions. Wonder if @madskristensen would be willing to help here, as this was an amazing extension for VS. Without it building projects is just a black box with a spinner.

[chucker]

So, I made a branch. It looks like something in 17.2 and beyond broke the binary compatibility of IVsSolutionBuildManager5. If I reference Microsoft.VisualStudio.SDK 17.0.31902.203 or newer, it works. If I reference 16.10.31321.278 or older, this returns null:

        _solutionBuildManager4 = await GetServiceAsync(typeof(SVsSolutionBuildManager)) as IVsSolutionBuildManager5;

I don't really understand why.

Anyway, as long as we're willing to throw away compatibility with VS 2019, there's no need for reflection; just update the references.

[chucker]

Not sure what's left for it to be completed.

I'm guessing he'd rather solve it without reflection. I'm not sure it's possible to do that while maintaining VS 2019 compat.

(This seems like a bug on MS's end.)

[PeterJarrettUK]

I reckon no major problem with losing VS2019 compatibility - if someone is still running 2019, then presumably they could stick with an older version? Maybe as a suggestion this is BuildVision 2022 - certainly many of the extensions I use have had to issue a 2022 version including a fair few of Mads' ones :-)

[StefanKert]

Hi folks,

so first of all, I am very sorry for all the inconveniences and troubles that the extension has caused in the new VS update. As of private reasons I did not have a lot of time in the last months to focus enough on BuildVision and the changes that have been introduced in VS 2022 hit the extension pretty hard. There have been some under the hood changes that will probably require to have a completely new version of BuildVision (very correct there @Mostlypyjamas :)). Currently the biggest blocking part is retrieving events for updates of the solution (as @chucker pointed out there is a missing package). As the version in the branch that has mentioned by @michael-hawker was already working in VS 2022 I guess there have been even more changes that make it impossible to work with VS 2022 now... sorry for that.

I actually was hoping that Microsoft would improve the Migration path as little and if I remember correctly there was a blogpost about having the option to package different multiple versions targeting old VS installations and also VS 2022 in a single extension, but since then I haven't seen any update on that (maybe @madskristensen or @lyrichardson01 can help out with an update).

So much on the current state.

Since the discussion has become very heated and I really didn't want to cause that much trouble I really want to say that all questions and input is valued, obviously also including questions for an ETA or a schedule.

I know that many people are using this extension as part of their daily routine so as with everything else I would also ask for an ETA for things I love and care about. There is absolutely nothing wrong with that as long as it is formulated with respect and in my opinion that definitely was the case.

So as the maintainer of this project I can just again try to assure you that every opinion and every post is valued because I do think that every comment / issue is a contribution to the project as well, because every issue that is being raised is also potentially affecting someone else. Contributions to Open Source is more than adding code IMHO.

Since I guess the most important part now is to get BuildVision working again with VS 2022, I'll try to see what we are missing and probably compare with @chucker s branch, probably that can be reused to make it work.

If it still is not possible to having both supported things in a single version I'll go ahead and create a new extension (e.g. BuildVision 2022), but for obvious reasons I would really love to prevent that from happening.

I can't give you a timeline yet since I am still pretty busy with other things, but I can promise you that I'll try to prioritize it a bit so that VS 2022 support is in soon.

So thanks again to everyone adding comments, asking for updates, or assistance. I really appreciate input of any sort and hope that we'll continue this with respect and openess.

Thanks folks :)

[StefanKert]

Hi folks,

so quick update from my end. I am afraid that we will not have the possibility to have a single BuildVision extension working properly for VS2022 (+ Out Of Process) and VS 2019. Also I really think that the new model available in VS 2022 can help BuildVision gain additional performance and decrease the impact.

Having said that there are actually two options and I just wanted to share them very quick.

1. New extension BuildVision x64 targeting only VS 2022

This is afaik the most used option for other extensions. So here is an example of the AddNewFiles extension created by @madskristensen

Benefit of this option is that we could still have fixes for the VS 2019 extension (potentially also including new features), but still being able to run it on VS 2022 with all the new benefits

2. Drop Support for VS 2019

As far as I understood there are still many people using VS 2019 or so IMO this is not really an option. I really can't say right now how many people are still using older versions, but I don't think that this is an actual option.

3. New extension BuildVision 2019

So similar to option 1 this would involve creating a new extension that would require everyone using pre 2022 to install this extension to being able to upgrade. Also not ideal I guess since it would require a change on all these installations.

Summing things up I guess creating BuildVision x64 would be the best option IMHO as this is currently also the recommendation from Microsoft.

If anyone got any thoughts on that or can think of another option that we can choose to make the upgrade path smoother please just share :).

I will also try to reach out to some folks at microsoft and see if there is any update on the roadmap for the multi extension distribution, but I assume that this will not be in to soon.

[chucker]

If anyone got any thoughts on that or can think of another option that we can choose

I asked over on the community toolkit repo, and apparently, you can publish multiple versions under the same name.

[StefanKert]

@chucker wow I have totally overlooked that. So I am not sure though if that also works for VS 2019 because the blogpost explicitly states "if you have upgraded your extension."

I was also very quickly checking the mentioned extension in the marketplace and currently I don't have this option to download the different architectures. Also the code doesn't in the github repo doesn't have the necessary bits for that.

Does anyone else have the multi-download option shown in the blogpost?

From my perspective it looks like the differing architecture / different vs for a single extension is something that the marketplace is offering so probably something in the backend there?

There is also a section on that in the migration docs https://learn.microsoft.com/en-us/visualstudio/extensibility/migration/update-visual-studio-extension?view=vs-2022#visual-studio-marketplace

So I guess there must be a way. So that would be option 4 and actually the preferred one from my end. So probably someone else knows more about this or can point me to a article about that.

[kenny1983]

Dude...I get it OK? I'm a developer myself and yes, nagging users are the worst. Especially ones that blatantly disregard the well-known etiquette of matters like this.

You know what's even worse though? People who discourage contribution to a project by lashing out about it. Did you have your cranky pants on when you wrote that? Or had you just not eaten in a while?

I was thinking about taking a look into this issue even though I'd never even heard of this extension until 6 hours ago, because it seems like a very useful one. Then I read the whole thread, cringed myself at the nagging for updates, and read your chastisement. And I just felt a bit sorry for Janek91.

Maybe they deserved it; as I said before I do totally understand where you're coming from, but this whole thing has just left a really bad taste in my mouth.

Just my two cents, take from it what you will.

On Sat, 17 Sept 2022, 6:25 am Mitch Capper (they, them), < @.***> wrote:

Wow...I totally get where you're coming from mate, but geez, that was just a bit harsh don't you think??

Yes. As subtly generally doesn't seem to work. The developer previously stated

-

I'll do further checks and keep you posted :)

@latenightsurfer https://github.com/latenightsurfer then felt asking the developer if they could estimate when it would be fixed was appropriate

jzabroski then pointed out the fact its open source so if you need it fixed you are welcome to contribute to do so and the fact these questions annoy many developers.

Then @Janek91 https://github.com/Janek91 commented another useless comment of essentially whats going on with the fix?

These things to me show either @Janek91 https://github.com/Janek91 did not read or think through the comments thus far to realize how that is likely to be annoying, or they did and decided hey who cares im going to ask for an update anyway. This is also reinforced as they directed the update request to a user who isn't a contributor on this project. Further, if the dev didn't respond to @latenightsurfer https://github.com/latenightsurfer why should you expect them now to answer you?

As clearly jazbroski's comment was either not understood nor not headed it seemed something more blunt was in order. Janek is not new to GH and likely aware how these thing work as well.

All of this is not a new phenomenon to say the least, it happens on most projects and annoys most developers and even when someone has already pointed that out in this very bug report it is ignored and the me first give me an update approach is still taken.

@kenny1983 https://github.com/kenny1983 comes along and mistakenly assuming I was the developer essentially said: Boy how rude you are, I will never even think about supporting this extension in the future. Now I am not sure if that means @kenny1983 https://github.com/kenny1983 has provided support for it in the past, or was about to make some contribution, (or more than likely neither) but lets think about that statement. They were mad as they thought the developer was being rude, however jzabroski tried to point it out in a nicer fashion, no luck. As not the project owner I can make my comment and hopefully these sorts of users will finally get why these actions are potentially so annoying for so many without a lot of backlash on the actual owner.

— Reply to this email directly, view it on GitHub https://github.com/StefanKert/BuildVision/issues/120#issuecomment-1249780787, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACHCHCXNVN6DTHW6X7MRVITV6TJTVANCNFSM5UWGXLBQ . You are receiving this because you were mentioned.Message ID: @.***>

[mitchcapper]

You know what's even worse though? People who discourage contribution to a project by lashing out about it.

One can't have something worse than the worst, but we will just assume you were going for me being the worst of the worse. Hopefully, as you read this read, it has become clear that I am not the developer of this plugin and further the developer directly disagrees with my statements. They have even stated they value all voices even those asking for input.

I was not "cranky" but again trying to voice what is a very common position for many projects. Often developers don't want to be more blatant, lest someone come along and get mad, throw a tantrum, or never support the project again.

So again, the developer here has quite directly stated my position is wrong and clearly was not helpful in any way here. I not only apologize for this but for causing more drama and off topic replies when my goal was actually to reduce the comment spam in the thread.

@StefanKert have you considered having two versions built, but in the same package using different dynamically loaded dlls? One obvious/easy path is to create a simple initialization interface that both dlls have classes implementing and then use Assembly.Load with version detection. A more complex/non Assembly.Load method would be to have two sets of namespaces in the two dlls. The ensure you never touch anything in the other vs's namespace and .net will naturally not load the other dll until it is needed (which is then hopefully never). I can't say this is super recommended as anything else in the process (which clearly is not under our control) could use reflection or just get types that would force the dll to load and jig up.

[chucker]

have you considered having two versions built, but in the same package using different dynamically loaded dlls? One obvious/easy path is to create a simple initialization interface that both dlls have classes implementing and then use Assembly.Load with version detection.

It's not Stefan's assembly that needs to versions, but rather a Microsoft dependency. It may be possible to place all those in two separate subdirs and dynamically load one or the other, but I'm not sure that's worth the effort.

[mitchcapper]

It's not Stefan's assembly that needs to versions, but rather a Microsoft dependency. It may be possible to place all those in two separate subdirs and dynamically load one or the other, but I'm not sure that's worth the effort.

Yeah, essentially they could have 3 projects the base project, and then the two vs 2022 and vs2019 projects which could reference different packages use a shared project for 99% of the code. Essentially a plugin architecture and one doesn't need to worry about which sub deps to load as just by adding the right sub directory for resolution all the binaries would come from there rather than the other version.

[Adrian-Grimm]

FYI: https://github.com/Adrian-Grimm/BuildVision/releases/tag/3.1.0.8

[PeterJarrettUK]

FYI: https://github.com/Adrian-Grimm/BuildVision/releases/tag/3.1.0.8

Hi Adrian - sadly that build of the extension still fails to load on my VS2022 Professional - the usual "The BuildVisionPackage package did not load correctly.

[Adrian-Grimm]

That one also? https://github.com/Adrian-Grimm/BuildVision/releases/tag/3.1.0.9 In my case it works ... I just had to uninstall the old ones...

[PeterJarrettUK]

That one also? https://github.com/Adrian-Grimm/BuildVision/releases/tag/3.1.0.9 In my case it works ... I just had to uninstall the old ones...

Sorry, still no luck: the error in the activity xml shows as below

The exact visual studio version is 17.5.5

  <entry>
    <record>2859</record>
    <time>2023/05/17 15:51:03.693</time>
    <type>Error</type>
    <source>VisualStudio</source>
    <description>SetSite failed for package [BuildVisionPackage]Source: &apos;BuildVision&apos; Description: Method not found: &apos;Microsoft.VisualStudio.Threading.JoinableTaskFactory Microsoft.VisualStudio.Shell.AsyncPackage.get_JoinableTaskFactory()&apos;.&#x000D;&#x000A;System.MissingMethodException: Method not found: &apos;Microsoft.VisualStudio.Threading.JoinableTaskFactory Microsoft.VisualStudio.Shell.AsyncPackage.get_JoinableTaskFactory()&apos;.&#x000D;&#x000A;   at BuildVision.Core.BuildVisionPackage.&lt;InitializeAsync&gt;d__22.MoveNext()&#x000D;&#x000A;   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine&amp; stateMachine)&#x000D;&#x000A;   at BuildVision.Core.BuildVisionPackage.InitializeAsync(CancellationToken cancellationToken, IProgress`1 progress)&#x000D;&#x000A;   at Microsoft.VisualStudio.Shell.AsyncPackage.&lt;&gt;c__DisplayClass21_0.&lt;&lt;Microsoft-VisualStudio-Shell-Interop-IAsyncLoadablePackageInitialize-Initialize&gt;b__1&gt;d.MoveNext()&#x000D;&#x000A;--- End of stack trace from previous location where exception was thrown ---&#x000D;&#x000A;   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()&#x000D;&#x000A;   at Microsoft.VisualStudio.Services.VsTask.RethrowException(AggregateException e)&#x000D;&#x000A;   at Microsoft.VisualStudio.Services.VsTask.InternalGetResult(Boolean ignoreUIThreadCheck)</description>
    <guid>{837C3C3B-8382-4839-9C9A-807B758A929F}</guid>
    <hr>0x80131513</hr>
    <errorinfo></errorinfo>
  </entry>

[Adrian-Grimm]

ah OK I've just tested it with 17.6 - maybe update your VS...

[PeterJarrettUK]

Yep thats got it!!! Upgraded to 17.6 and now it's working nicely

I'm loving seeing it back in action - I'd forgotten how much I relied on it having been without it for so long - great work :-)

[AgWillo]

@Adrian-Grimm: Working for me on VS (Enterprise) 17.6. Thank you!

[andre259]

So glad to see this back in action, thanks for all your hard work!

[ankit-mishra-mt]

That one also? https://github.com/Adrian-Grimm/BuildVision/releases/tag/3.1.0.9 In my case it works ... I just had to uninstall the old ones...

v3.1.0.9 is working fine on VS 2022 Preview (Version 17.7.0 )

[richardcox13]

That one also? https://github.com/Adrian-Grimm/BuildVision/releases/tag/3.1.0.9 In my case it works ... I just had to uninstall the old ones...

v3.1.0.9 is working fine on VS 2022 Preview (Version 17.7.0 )

And is working on (after brief test) VS 2022 V17.7.0 (yesterday's release).

[IwishIcanFLighT]

That one also? https://github.com/Adrian-Grimm/BuildVision/releases/tag/3.1.0.9 In my case it works ... I just had to uninstall the old ones...

v3.1.0.9 is working fine on VS 2022 Preview (Version 17.7.0 )

And is working on (after brief test) VS 2022 V17.7.0 (yesterday's release).

Can confirm this release also works with VS 2022 17.8.1 👍 Thanks!

[onur-ozguzel]

That one also? https://github.com/Adrian-Grimm/BuildVision/releases/tag/3.1.0.9 In my case it works ... I just had to uninstall the old ones...

Works with: Microsoft Visual Studio Enterprise 2022 (64-bit) Version 17.7.6

Thanks!

[StefanKert]

Hi folks,

a Preview of version 4.x is available in the VSIX Gallery feed. You can follow along with the installation instructions from the README https://github.com/StefanKert/BuildVision?tab=readme-ov-file#setup-visual-studio-for-preview-channel. Would love to hear if this fixes the issues you are facing. As soon as the issues that people are currently seeing are resolved there will be a official marketplace release.

Thanks :)

[meld-cp]

Hey @StefanKert,

First, thanks for building this extension.

I started using preview v4.x today and I noticed that the error, warning and info counts don't seem to be working... or maybe I missed an option to turn those on?

[StefanKert]

Hi @meld-cp ,

thank you so much for checking. The issue was related to VS 2022 doing a different way of registering MS Build loggers. The latest version that is in the Gallery fixed this issue for me, but since some of the installations behave differently, I am not sure if this is a fix for you as well so if you got a few minutes to double check please let me know if counts are showing up for you correctly with the latest release. The new version is 4.0.0.10 :) thanks a lot

[meld-cp]

Thanks... No problem at all @StefanKert , I'll give it a try for sure... It won't be for a couple of days though, but will report back. 👍

[meld-cp]

Hi @StefanKert, same issue for me unfortunately:

Reach out if you need more testing done.

Microsoft Visual Studio Professional 2022 (64-bit) - Preview
Version 17.10.0 Preview 6.0