Digital signature from Microsoft is missing for the scripts

[steamonimo]

I am expecting Microsoft to digitally sign its powershell scripts. This might make the process in a rolling github relase more cumbersome. On the other hand the process of digitally signing the scripts can be automated. In the current state the unsigned script violates the execution policy on all Windows systems:

CouldNotAutoloadMatchingModule - script not signed!

[heaths]

I can consider this, but it will still prompt to trust the publisher. Feedback in the past for OSS PowerShell modules I've done is to not sign (if this were developed internally and released it certainly would be).

[steamonimo]

Thanks for considering. Actually I assumed that Microsoft signed Powershell Scripts are trusted for everyone. For me the signment is the next logical step when the scripts can be conveniently downloaded via git automation in one command.

[heaths]

Nope. All PowerShell scripts regardless of signer prompt to trust the publisher. Now, if the publisher is the same and already trusted from another script it should just work.

But what do you mean about "git automation in one command"? I do publish these to http://powershellgallery.com so you can use install-module vssetup (with default sources, or even specify a source if you want to constrain to just the gallery). Whether signed or not won't change any of those prompts. You can also call Set-ExecutionPolicy Bypass (or whatever policy) on a build or start powershell.exe -executionPolicy bypass to aovid those cases. The latter is what we typically do to avoid surprises from machine to machine.

[steamonimo]

My fault, I assumed that git was the source used by "install-module vssetup". In this context of more or less "trustworthy" repositories the digital signature makes sense to me. I am fine if this means I must accept the signer "Microsoft" once for the machine.

I know your time is precious: but do you have any idea how the edition of the installed visual studio can be identified? The VS Installer does not install a software id tag for identification (ISO 19770-2). I am also a bit puzzled that the WMI class SoftwareLicensingProduct will not reveal any info about the installed Visual Studio Edition. From the perspective of asset management solutions it would be highly recommendable to just use one mechanism to report the Edition for all Microsoft products. Here the Office did establish the WMI approach and it would be nice if the dev teams for all other products would just adopt that.

[heaths]

The installer is not really VS-specific, so there's no concept of edition. You can, however, Product property of an instance which includes the package ID as follows:

Edition	Package ID
Community	Microsoft.VisualStudio.Product.Community
Professional	Microsoft.VisualStudio.Product.Professional
Enterprise	Microsoft.VisualStudio.Product.Enterprise

These are documented also at http://aka.ms/vs/workloads

I can backlog those ideas for consideration in the future. The WMI class is for products that use Windows licensing service. Visual Studio has not and does not use this service. We have our own licensing model.

[steamonimo]

Many thanks!

Is MsiGetProductInfo from the msi.dll the correct approach to get these properties? Our clients are purely C++ and I need to access the product properties from there.

Update: the source code of vswhere is the perfect demonstrator to achieve that!

It would be nice to backlog my input. Right now the situation is that the identification of the Editions for Windows, SQL Server, Exchange, Visual Studio and others are all very different. For Visio, Office and Project we have the WMI approach via SoftwareLicensingProduct. It would be nice to consolidate on WMI because this information can be verified by humans via wbemtest. This way customers, auditors and tools can independently verify the information.

[heaths]

MsiGetProductInfo is only for Windows Installer packages. We install very few anymore, instead opting for a ZIP format with optional additional - but limited - processing for a nearly xcopy-deployable installation. As a result, there are different ways of detecting editions and they are different across products because each uses different installers. We are considering ways of exposing information in a more consistent manner, but it definitely would not be through the SoftwareLicensingProduct class because we don't use that infrastructure. Perhaps a CIM_Product derivative, like Win32_ComputerSystemProduct and Win32_Product (MSIs). Still, neither have edition because edition is specific to a product, and MSIs and our new installer install products that don't always have an edition. But the Product property is effectively equivalent as shown in the table above. You can either extract the string edition, or just treat the opaque string as the edition since they are equivalent representations.

[steamonimo]

With simplicity and file orientation in mind I would really prefer the software id tags of ISO 19770-2. Just include the file with the ending swidtag in the installation package. Even products using keys to unlock specific features could use these simple xml files to document their licensing state. If the unlocking changes the Edition then the xml file just has to be rewritten by the unlock process. Most SAM tools should support these tag files because it is an official ISO standard. In my opinion the easiest approach to support external asset management solutions. Thanks for your time!