TestDriven.Net doesn't appear in Visual Studio 2017 / 15.3

[jcansdale]

From: @bradwilson

Just rebuilt my box with VS2017 Enterprise 15.3 and TDnet 4.0.3525, but the plugin doesn't show up inside VS. I double checked, VS2017 Enterprise is one of the listed choices during TDnet install. Any idea what's going on?

Something appears to have changed in the latest VS15.3, that prevents devenv.exe /updateconfiguration from working when executed from an installer. This command lets Visual Studio know there are changes in the Common7\IDE\Extensions directory and to update its state. This this doesn't work then then new menu items won't appear.

It appears that devenv.exe /setup (when executed after installation from a administrator command prompt) will cause the menu items to appear. Surprisingly devenv.exe /updateconfiguration also works, even when executed from a non-administrator prompt. Alternatively, editing the Extensions\extensions.configurationchanged file will also cause Visual Studio to update its state on next load.

[jcansdale]

Here are a couple of posts that document how devenv /updateconfiguration or touching extensions.configurationchanged will cause Visual Studio to refresh its state:

http://blogs.clariusconsulting.net/kzu/how-to-install-a-visual-studio-extension-with-templates-via-an-msi/
https://hmemcpy.com/2014/03/installing-vsix-extension-via-msi-without-devenv-setup/

[jcansdale]

I tried @kzu's WiX CustomAction, which does seems to work when executed within the installer.

    <CustomAction Id='VISUALSTUDIO_150_COMMUNITY_UPDATE_CONFIGURATION'
                  Directory='D__Extensions_150_Community'
                  Execute="deferred"
                  Impersonate="no"
                  ExeCommand='[SystemFolder]cmd.exe /c &quot;copy /b extensions.configurationchanged +,,&quot;'
                  Return='ignore' />

This alternative also works (which I'm currently using). Having a "." written to extensions.configurationchanged is a useful sanity check:

    <CustomAction Id='VISUALSTUDIO_150_COMMUNITY_UPDATE_CONFIGURATION'
                  Directory='VISUALSTUDIO_150_COMMUNITY_INSTALLDIR_PACKAGE'
                  Execute="deferred"
                  Impersonate="no"
                  ExeCommand='[SystemFolder]cmd.exe /c &quot;echo . &gt; Extensions\extensions.configurationchanged&quot;'
                  Return='ignore' />

[jcansdale]

I can't work out why devenv /updateconfiguration no longer seems to work. It does appear to change the date on extensions.configurationchanged, just like @kzu's custom action.

@kzu Any idea what might be going on? I'm stumped. 😭

[kzu]

That devenv call should work. Does it work if you issue it manually from the command line? Also, sometimes you need to start VS as admin *once* after doing that. In any case, it should be reported as VS feedback, since that's THE mechanism to update VS :S

On Sun, Aug 27, 2017 at 8:19 PM Jamie Cansdale ***@***.***> wrote: I can't work out why devenv /updateconfiguration no longer seems to work. It does appear to change the date on extensions.configurationchanged, just like @kzu <https://github.com/kzu>'s custom action. @kzu <https://github.com/kzu> Any idea what might be going on? I'm stumped. 😭 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#104 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKW6zZeUlWmMSSyPkmSC3kwmH24nH0dks5scfl8gaJpZM4PD7G0> .

--

…

-- /kzu from mobile

[jcansdale]

That devenv call should work. Does it work if you issue it manually from
the command line?

When executed from the MSI, the date on extensions.configurationchanged changes but Visual Studio doesn't update afterwards. I even tried deleting extensions.configurationchanged. In this case a new extensions.configurationchanged is created but Visual Studio still doesn't update itself.

If I execute devenv /updateconfiguration after installation, it does work. 😕

I wonder if when Visual Studio gets updated has changed? I know this used to happen on first load. Now devenv /updateconfiguration is taking considerable longer to execute. Maybe Visual Studio now gets updated when this executes?

[jcansdale]

I've just had a look with Sysinternals Procmon and think I can see what's happening:

In previous versions of Visual Studio 2017, devenv /updateconfiguration would simply touch the extensions.configurationchanged file and Visual Studio would be initialized on first launch. On the new 15.3 release, it looks like Visual Studio is being initialized as part of devenv /updateconfiguration.

This usually wouldn't be an issue, but it looks like I'm calling devenv /updateconfiguration before the TestDriven.VSPackage.pkgdef file is created. Visual Studio is now being initialized before TestDriven.Net has been installed.

That's what I think is happening anyway. Time to refresh my memory of WiX and MSI installers. 😉

[jcansdale]

Fixed in this build: TestDriven.NET-4.1.3529_Extraterrestrial_Alpha.zip

Fixed in recent versions on website:
http://testdriven.net/download.aspx

[Jiedy]

In the vs2017 15.4.4 version, try the devenv /updateconfiguration method, still doesn't appear(Version TestDriven.NET-4.1.3531) :(，Is there any other way?Help~~~

[jcansdale]

@Jiedy,

Could you try installing the latest version from the website?
http://testdriven.net/download.aspx

This issue should be fixed. Let me know how you get on.

[Jiedy]

Thx~!,I installed the latest version(TestDriven.NET-4.1.3531_Personal_Beta),It appears! :)

[skolod]

I installed Personal TestDriven.NET-4.1.3531 Beta from the site in MS VS 2017 15.4. TestDriven.Net menue items were not appeared. Tried to run "devenv.exe /updateconfiguration" and "devenv /setup". No effect.

[jcansdale]

@skolod,

When installing for Visual Studio 2017 Personal, TestDriven.Net will install itself here:
\Program Files (x86)\Microsoft Visual Studio\2017\Personal\Common7\IDE\Extensions\TestDriven

Could you check that there is a folder in that location and that it's the same path that VS is installed at?

[skolod]

@jcansdale,
thank you for the quick answer. Yes, locations corresponds that you described. And I can see TDN in Visual Studio in Tools/Options/ menu, but there are no TDN menue items in context menu. When I open VS I can see at the beginning a message on the left side of status bar somthing like "Couldn't find InstallDir for TestDriven.Net".

[jcansdale]

@skolod I'm afraid I missed your reply come in. If this is still a problem could you open a new issue. Whatever is causing InstallDir to not be found is different to the main issue.

Closing because the menu items not appearing due to the order the installer was initializing the extension was fixed in 4.1 RTM (it now initializes after installing the files).