16

How can I check/detect which Visual Studio version is running under my VSPackage?

I cannot get from the registry because the computer could have several versions installed, so I guess there is an API that is able to get it.

Anybody knows how to get it from a managed Visual Studio package using C#?

AndrewR
  • 6,668
  • 1
  • 24
  • 38
Daniel Peñalba
  • 30,507
  • 32
  • 137
  • 219

6 Answers6

17

You could try to get version via automation DTE object. In MPF you could get it in this way:

EnvDTE.DTE dte = (EnvDTE.DTE)Package.GetGlobalService(typeof(EnvDTE.DTE));

There are some other related things to retrieve DTE object - via Project.DTE, also read this thread if you're getting null for DTE.

Then you can get the version by using DTE.Version property.

Also useful information could be found on Carlos Quintero (VS addin ninja) website HOWTO: Detect installed Visual Studio editions, packages or service packs

Dmitry Pavlov
  • 30,789
  • 8
  • 97
  • 121
10

Finally I wrote a class to detect the Visual Studio version. Tested and working:

public static class VSVersion
{
    static readonly object mLock = new object();
    static Version mVsVersion;
    static Version mOsVersion;

    public static Version FullVersion
    {
        get
        {
            lock (mLock)
            {
                if (mVsVersion == null)
                {
                    string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "msenv.dll");

                    if (File.Exists(path))
                    {
                        FileVersionInfo fvi = FileVersionInfo.GetVersionInfo(path);

                        string verName = fvi.ProductVersion;

                        for (int i = 0; i < verName.Length; i++)
                        {
                            if (!char.IsDigit(verName, i) && verName[i] != '.')
                            {
                                verName = verName.Substring(0, i);
                                break;
                            }
                        }
                        mVsVersion = new Version(verName);
                    }
                    else
                        mVsVersion = new Version(0, 0); // Not running inside Visual Studio!
                }
            }

            return mVsVersion;
        }
    }

    public static Version OSVersion
    {
        get { return mOsVersion ?? (mOsVersion = Environment.OSVersion.Version); }
    }

    public static bool VS2012OrLater
    {
        get { return FullVersion >= new Version(11, 0); }
    }

    public static bool VS2010OrLater
    {
        get { return FullVersion >= new Version(10, 0); }
    }

    public static bool VS2008OrOlder
    {
        get { return FullVersion < new Version(9, 0); }
    }

    public static bool VS2005
    {
        get { return FullVersion.Major == 8; }
    }

    public static bool VS2008
    {
        get { return FullVersion.Major == 9; }
    }

    public static bool VS2010
    {
        get { return FullVersion.Major == 10; }
    }

    public static bool VS2012
    {
        get { return FullVersion.Major == 11; }
    }
}
Daniel Peñalba
  • 30,507
  • 32
  • 137
  • 219
  • 1
    This solution makes sense compared to DTE.Version, since sooner or later DTE will be deprecated from VS API (the same way VS addin technology got deprecated). The proposed code can be enhanced by using fvi.FileMajorPart and fvi.FileMinorPart that returns two integers, this avoids the string parsing part in the proposed code. – Patrick from NDepend team Jul 02 '14 at 13:09
  • +1 because this code retrieves the full version (e.g. 11.0.61030.00) that can be used to infer the update-level of VS. DTE.Version only returns e.g. "11.0" – frank koch Jul 14 '14 at 18:44
  • Any reason to prefer msenv.dll over devenv.exe? Just curious. Also: wonder if there is really locking required? – Haymo Kutschbach Nov 03 '14 at 09:25
  • Visual Studio shell based applications other than Visual Studio use a different executable than devenv.exe... they all use msenv.dll. – Bert Huijben Feb 29 '16 at 00:10
2

I think the following code is better:

string version = ((EnvDTE.DTE) ServiceProvider.GlobalProvider.GetService(typeof(EnvDTE.DTE).GUID)).Version;
Shahyad Sharghi
  • 660
  • 9
  • 12
2

To get the full semantic version that includes the patch numbers, like "15.9.6", neither DTE.Version nor the file versions give sufficient information.

I have found a solution in the new managed project system (https://github.com/dotnet/project-system) that seems to be working in VS2017 at least.

Basically, it is using the IVsAppId COM interface, that you need to declare, like in this file. (You can basically copy that file as it is.)

Once you did that, you need to get the IVsAppId implementation in the usual way through a service provider, and call the GetProperty method with VSAPropID.VSAPROPID_ProductSemanticVersion (the enum is also defined in the linked file):

var vsAppId = serviceProvider.GetService<IVsAppId>(typeof(SVsAppId));

vsAppId.GetProperty((int)VSAPropID.VSAPROPID_ProductSemanticVersion, out var semanticVersionObj);

The semanticVersionObj in the sample above will contain a string, in format, like 15.9.6+28307.344. Getting the part before + (sometimes -) gives you the semantic version: 15.9.6.

BTW: it is used in the managed project system here.

(It is so great that MS made the new project system code open source. It provides a good source of information and also you can find useful patterns in it.)

Gaspar Nagy
  • 4,422
  • 30
  • 42
  • Tested all answers and this one provides the closest VS version. For my VS2019 16.9.4 it is "16.9.4+31205.134". At the same time the DTE version is just 16.0. The shell version form the @TWT answer below is "16.0.31205.134 D16.9", The file version from the accepted Daniel Peñalba answer is "16.0.31201.295" for msenv.dll and "16.9.31205.134" for devenv.exe. No other versions contain anything related to the minor VS version. The only downside for me is that I could not find any info on IVsAppId interface, so it looks like an internal undocumented feature which may break in the future. – SENya May 10 '21 at 19:28
1

@gaspar-nagy answer provides the most precise version. However, it can be further enhanced. Like the answer advices you need to add IVsAppId/SVsAppId interfaces declarations and the code to get the version is also almost the same. However, you need to use the VSAPROPID_ProductDisplayVersion enum value instead of VSAPROPID_ProductSemanticVersion from the VSAPropID enum:

var vsAppId = serviceProvider.GetService<IVsAppId>(typeof(SVsAppId));
vsAppId.GetProperty((int)VSAPropID.VSAPROPID_ProductDisplayVersion, out var versionObj);

The semantic version from @gaspar-nagy answer for my VS 16.9.4 is "16.9.4+31205.134" which requires further parsing. But this display version is user friendly and its version is "16.9.4".

UPDATE: One important thing I've discovered recently is that in case of preview VS the version string in my answer will look something like 16.11.0 Preview 3.0. It may be important if you pass the obtained raw version string without any extra processing to some other APIs like System.Version constructor.

SENya
  • 1,083
  • 11
  • 26
0
var shell = _package.GetService(typeof(SVsShell)) as IVsShell;
shell.GetProperty((int)__VSSPROPID5.VSSPROPID_ReleaseVersion, out object ver);
return ver.ToString();
TWT
  • 2,511
  • 1
  • 23
  • 37
  • While this code may help with the question, it is better to include some context, explaining how it works and when to use it. Code-only answers tend to be less useful in the long run. See [How do I write a good answer?](https://stackoverflow.com/help/how-to-answer) for some more info. – Klaus Gütter Oct 07 '19 at 16:55