I need to be able to let a user install a product on XP, Vista, Server 2003 and Server 2008, both x86 and x64 editions.

The product includes a Visual Studio Add-In.

I am utterly confused over where to put the add-in, Ive scoured the web and found several articles that simply confuse me more.

It looks like I may need to see what OS user is running, then see what add-in folders may exist for that OS and then select one.

Given the effort MS have made to support add-ins, it strikes me as almost ridiculous that I cant simply call some method to get this.

e.g.

Microsoft.VisualStudio.Platform.GetAddInFolders();

for example.

What is the best approach to addressing this?

I'd also like to be able to tell if the user (or the machine) actually has Visual Studio installed.

I though the Add-In itself was hard work, but this is just too much.

H

Hello,

The official MSDN Doc about add-in folders for VS 2008 is:

Add-in Security
http://msdn.microsoft.com/en-us/library/1326zbk3.aspx

which has a note that says "Some of the default paths may resolve to targets that do not exist on your system.". That is, if the folder that you want to use doesn't exist the setup of your add-in must create it.

About the missing "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\<version>\Setup\VS\<edition>", which exact VS 2008 edition (Standard, Professional, Developer Edition, Team Suite, etc.) are you using? At least with VS 2008 Team Suite on Windows XP and Windows Vista the registry entry exists.

---

MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about VS extensibility: http://msmvps.com/blogs/carlosq/

About your frustrations with add-in folders, I totally agree. See:

http://msmvps.com/blogs/carlosq/archive/2009/01/16/the-strange-case-of-quot-allusersprofile-datos-de-programa-microsoft-msenvshared-addins-quot-add-in-file-path.aspx

---

MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about VS extensibility: http://msmvps.com/blogs/carlosq/

See:

INFO: Default .AddIn file locations for Visual Studio add-ins
http://www.mztools.com/resources_vsnet_addins.aspx

(Bottom line: use %VSCOMMONAPPDATA%\AddIns)

HOWTO: Detect installed Visual Studio editions, packages or service packs
(same link)

---

MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about VS extensibility: http://msmvps.com/blogs/carlosq/

See:

INFO: Default .AddIn file locations for Visual Studio add-ins
http://www.mztools.com/resources_vsnet_addins.aspx

(Bottom line: use %VSCOMMONAPPDATA%\AddIns)

HOWTO: Detect installed Visual Studio editions, packages or service packs
(same link)

---

MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about VS extensibility: http://msmvps.com/blogs/carlosq/

Thanks Carlos

I appreciate the help, can you tell me which particular articles/pages I should explore (there are a lot of them on that site).

Many thanks

Hugh

can you tell me which particular articles/pages I should explore (there are a lot of them on that site).

Default .AddIn file locations for Visual Studio add-ins

Hello,

INFO: Default .AddIn file locations for Visual Studio add-ins
http://www.mztools.com/Articles/2008/MZ2008001.aspx

HOWTO: Detect if Visual Studio .NET is installed in a Visual Studio Setup package for an add-in.
http://www.mztools.com/articles/2006/MZ2006001.aspx

HOWTO: Detect installed Visual Studio editions, packages or service packs
http://www.mztools.com/articles/2008/MZ2008003.aspx

---

MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about VS extensibility: http://msmvps.com/blogs/carlosq/

can you tell me which particular articles/pages I should explore (there are a lot of them on that site).

Default .AddIn file locations for Visual Studio add-ins

Thanks to both of you.

Now the second example is the best (because it works for either XP or Vista).

But on my Vista x64 box with VS 2008, there is a folder called "C:\ProgramData\Microsoft\VisualStudio\9.0"  but that folder contains NO sub folder called 'Addins'.

Am I expected to create it if it doesn't yet exist? if so this fact should be documented.

Also, on the same box, there is NO folder called "MSEnvShared" inside "C:\ProgramData\Microsoft".

This is what confuses me, I really have no idea which folders ALWAYS exist, which folders MAY NOT exist and which folders I MUST CREATE (in my installer).

Where is the official Microsoft documentation for all this anyway? did they not write any?

Thanks

Cap'n

Hello,

INFO: Default .AddIn file locations for Visual Studio add-ins
http://www.mztools.com/Articles/2008/MZ2008001.aspx

HOWTO: Detect if Visual Studio .NET is installed in a Visual Studio Setup package for an add-in.
http://www.mztools.com/articles/2006/MZ2006001.aspx

HOWTO: Detect installed Visual Studio editions, packages or service packs
http://www.mztools.com/articles/2008/MZ2008003.aspx

---

MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about VS extensibility: http://msmvps.com/blogs/carlosq/

Also Carlos

This folder "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\<version>\Setup\VS\<edition>" does not exist in my machines registry either, you use this to detect what version etc has been installed.

H

Hello,

The official MSDN Doc about add-in folders for VS 2008 is:

Add-in Security
http://msdn.microsoft.com/en-us/library/1326zbk3.aspx

which has a note that says "Some of the default paths may resolve to targets that do not exist on your system.". That is, if the folder that you want to use doesn't exist the setup of your add-in must create it.

About the missing "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\<version>\Setup\VS\<edition>", which exact VS 2008 edition (Standard, Professional, Developer Edition, Team Suite, etc.) are you using? At least with VS 2008 Team Suite on Windows XP and Windows Vista the registry entry exists.

---

MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about VS extensibility: http://msmvps.com/blogs/carlosq/

About your frustrations with add-in folders, I totally agree. See:

http://msmvps.com/blogs/carlosq/archive/2009/01/16/the-strange-case-of-quot-allusersprofile-datos-de-programa-microsoft-msenvshared-addins-quot-add-in-file-path.aspx

---

MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about VS extensibility: http://msmvps.com/blogs/carlosq/

Hello,

The official MSDN Doc about add-in folders for VS 2008 is:

Add-in Security
http://msdn.microsoft.com/en-us/library/1326zbk3.aspx

which has a note that says "Some of the default paths may resolve to targets that do not exist on your system.". That is, if the folder that you want to use doesn't exist the setup of your add-in must create it.

About the missing "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\<version>\Setup\VS\<edition>", which exact VS 2008 edition (Standard, Professional, Developer Edition, Team Suite, etc.) are you using? At least with VS 2008 Team Suite on Windows XP and Windows Vista the registry entry exists.

---

MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about VS extensibility: http://msmvps.com/blogs/carlosq/

Hi

Sorry Carlos, that folder actually does exist, but on x64 it is actually here (this is the part of the registry "seen" by 32-bit apps running on 64-bit OS).

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\Setup\VS perhaps it may be useful to point this out in your articles?

OK I will create that folder, the setup is for all users and must be run by Admin, so this will do fine.

It does seem like it would be very very very helpful if MS were to encapsulate all this stuff into some classes and just make it part of the support for extensibility, it could do everything, enumerate the paths, create the folder if need be, expose version/edition specific info and so on.



Thanks

Cap'n

Hello,

As long as the setup and they add-in are 32-bit applications, they should see the "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\" registry key as "HKEY_LOCAL_MACHINE\SOFTWARE\" so there is no need to make differences in the articles about Windows 32-bit / 64-bit. Or am I wrong? (I don't use Windows 64-bit yet...)

As for encapsulating all this stuff, the automation model (EnvDTE) is quite stagnated, very few things are added in new releases of VS. MS is doing most development in the VS SDK and in new ways of extensibility in VS 2010.

FWIW, the SDK has services that provide more information than EnvDTE, and can be called also from add-ins. One of my articles that I mentioned above (HOWTO: Detect installed Visual Studio editions, packages or service packs) shows that.

---

MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about VS extensibility: http://msmvps.com/blogs/carlosq/

Hello,

As long as the setup and they add-in are 32-bit applications, they should see the "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\" registry key as "HKEY_LOCAL_MACHINE\SOFTWARE\" so there is no need to make differences in the articles about Windows 32-bit / 64-bit. Or am I wrong? (I don't use Windows 64-bit yet...)

As for encapsulating all this stuff, the automation model (EnvDTE) is quite stagnated, very few things are added in new releases of VS. MS is doing most development in the VS SDK and in new ways of extensibility in VS 2010.

FWIW, the SDK has services that provide more information than EnvDTE, and can be called also from add-ins. One of my articles that I mentioned above (HOWTO: Detect installed Visual Studio editions, packages or service packs) shows that.

---

MZ-Tools: Productivity add-ins for Visual Studio: http://www.mztools.com. My blog about VS extensibility: http://msmvps.com/blogs/carlosq/

No, you are not wrong. But if someone is examining the registry in regedit then they NEED to know, because regedit shows all nodes for all apps.

Yes, code at runtime will work fine, but a person manually examining the registry will NEVER see certain keys, unless they deliberately look in the Wow6432Node subtree.

This is what caused me several hours of confusion, because in regedit I did NOT look beneath Wow6432Node, so I never saw the keys and values mentioned in your article (but executing code would see them).

Cap'n