11
Jun
2019

Change UI language in Visual Studio

The Visual Studio Installer for VS2019 automatically pulls the language package that matches the current Operating System. My Windows 10 Operating System language is currently German – there is a thing that always keeps me wondering:

Why is the Tools menu translated to Extras in German Visual Studio?

This and some more pecularities (especially important when working in pairs with non-German speakers) may be a good reasons to switch to old good English UI. Here is how to do it for an already installed Visual Studio 2019 instances (you can obviously apply this for any currently used language).

If target language pack has been already downloaded…

The only thing you have to do is to locate the correct settings. Go to Extras -> Optionen -> Umgebung -> Internationale Einstellungen and select the language from the list.

If target language pack has not been yet downloaded…

  1. Close all Visual Studio windows
  2. Run the Visual Studio installer. You can do this by going to Add/Remove Programs (Programme und Features) and selecting the right item. Press Ändern to bring the setup window.
  3. Go to the second tab and enable English language. You can disable German one if you do not plan to switch to it in future. Leaving just only new language enabled will automatically switch VS to that language. Press Ändern to apply the changes.
  4. In case you didn’t uninstall previous languages first, then after restarting you may need to go to Settings to change to the newly downloaded language pack. Simply go to Extras -> Optionen -> Umgebung -> Internationale Einstellungen and select the language from the list.

Installing language packs from command line

It is possible to automate installing language packs, by using the following command line (executed in directory where the installer resides, usually C:\Program Files (x86)\Microsoft Visual Studio\Installer):

vs_installer.exe modify --addProductLang En-us --path install="C:\Program Files (x86)\Microsoft Visual Studio\2019\Community" --quiet --wait

Note: The full installation path is required for this to work. I am using VS 2019 community installed in the default location, but you may update the path accordingly.

Instead of En-us for American English, any valid identifier from this list works too.

Posted by Marcin Otorowski in Programming, 0 comments
05
Jun
2019

Windows Sandbox – unable to run .NET apps

I have just updated my daily used computer to Windows 10 1903 May 2019 Update. The update took a while but after all finished with some nice new cool features on board.

I gave it a try and started the new Windows Sandbox mode, which is an out-of-the-box sandbox built in Windows 10 Pro and Enterprise. Launching of sandbox takes just a few seconds, and then the fully functional dummy environment is available, really well done!

One thing that I found interesting was that it was not possible to start a PowerShell window, or any .NET app. Each try finished with an error, for example:

This application requires one of the following versions of the .NET Framework:.NETFramework,Version=v4.5.2

The error dialog offers a choice to download the runtime, but the framework installer (correctly) prevents it from being installed, because that or a newer version is already there.

It turns out, that not everyone is affected by this problem. The problem is caused by update KB4495620 which is installed on the host machine. This is a cumulative update for .NET Framework fixing a few vulnerabilities. In order to be able to run .NET apps on Windows 10 Sandbox, uninstall this update and reboot your machine (again to repeat myself – this has to be done on your host and not the sandbox!). After that, powershell.exe and .NET apps will run without issues:

Hello World, RayPack 6.1 (.NET 4.5 app) is running on Windows 10 Sandbox mode.

I hope the problem is going to be fixed by Microsoft soon, until then use this workaround to test Windows 10 Sandbox out.

Posted by Marcin Otorowski in Virtualization, 2 comments
31
May
2019

Creating MSIX Packages with RayPack 6.1

Last week I was in London, and had a chance to speak to a few MS guys standing behind #MSIX. Also last week, a new version of RayPack Studio has been released, bringing some improvements over MSIX conversion in the latest revision 6.1. With this post I wanted to make a quick walkthrough of going from so-called legacy installations (traditionally all setup.exe and alike, but recently the Windows Installer format has been counted to that group) to the new, modern and native Windows-10 way of installing and servicing apps.

Installing Firefox in MSIX format (auto-conversion from MSI)
Continue reading →
Posted by Marcin Otorowski in MSIX, 0 comments
05
Mar
2018

Displaying installed MSI products with a PowerShell module

Based on my previous post, I created a small project on my github and adjusted existing codebase to provide a simplistic PowerShell module. The code has been reorganized into proper units with exported functions. Here is a sample usage:

$Header = @"
<style>
TABLE {border: 1px solid gray collapse; }
TH { border: 1px solid gray; padding: 6px 4px; background-color: #eaeaea; }
TD { border: 1px solid gray; padding: 4px; }
</style>
"@
Import-Module MsiClient
Get-MsiClientPackage | where { $_.Publisher -contains 'Microsoft Corporation' } | sort-object -Property ProductName | ConvertTo-Html -Property ProductCode,PackageName,ProductName,VersionString,Language,Publisher -Head $Header | Out-File c:\temp\test.html

The above snippet produces a HTML based report, showing all Microsoft products available on the current system.

There are still lots of TODOs, which I am going to cover soon, for example:

  • More methods supported (install, uninstall, repair etc.)
  • Better exception handling
  • Support for -WhatIf and -Confirm switches

In any case, my design goal is to keep the syntax similar to functions available in the AppVClient module, so that ideally for basic scenarios they have a 1-1 mapping in the MSI counterpart.

Link to my guthub (the project is licensed under MIT):
https://github.com/marcinotorowski/PowerShellMsiClient

Posted by Marcin Otorowski in Programming, 0 comments
04
Mar
2018

Enumerating installed MSI products with PowerShell and msi.dll

If you were ever wondering how to properly read the list of installed MSI software, then two popular choices are available:

  • Querying uninstall registry keys (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall), filtering out-non MSI entries and outputting the rest
  • Using Win32_Product from WMI

They both have their pros and cons. Querying registry is straightforward on its own, but requires awkward manipulations and accessing the data which is actually backing the Add/Remove Applet, not necessarily the Windows Installer API which uses its own complex registration. Additionally it may not work correctly with different installation context (user/machine) and you may have to query two places to get both x86 and x64 installations on a x64 system.

On the other hand, while WMI query is also pretty straightforward (see https://msdn.microsoft.com/en-us/library/aa394378(v=VS.85).aspx?f=255&MSPPError=-2147217396), it has a really big drawback. Running it is painfully slow, because Windows Installer checks integrity of each entry and triggers appropriate action (for example repair) if necessary.

So to have a solution which is both fast, reliable and without any side-effects, you may go for a third solution which is more complex, but once setup can be reused not only for querying but for a whole management of MSI-based installations. And so this blog today will be about P/invoking native msi.dll to get results returned by the true Windows Installer API.

This post may be too technical if you have never programmed in C/C++ or C#. If you just want the results without understanding how to implement them on your own, scroll to the bottom, the full content of the PowerShell script is there.
Continue reading →

Posted by Marcin Otorowski, 2 comments
27
Feb
2018

Make VMware Workstation 14 and VIX COM API work together

After installing newest VMware Workstation 14, it turned out that the automation API stopped working with the following error

Retrieving the COM class factory for component with CLSID{COMPONENT-ID} failed due to the following error: 80040154 Class not registered(Exception from HRESULT: 0x80040154(REGDB_E_CLASSNOTREG)).

It seems that the newest version does not install two important COM DLL files (and consequently does not register them): VIXCOM.dll and VIXCOM64.dll. The solution is to copy them over from older installation and register them (as administrator):

regsvr32.exe VIXCOM.dll
regsvr32.exe VIXCOM64.dll

Things start working after this little trick. Alternatively, a full VIX API 1.15 has to be installed (it is available as a separate download from VMware support pages).

The problem has been tackled by our support and is described here
https://raynetgmbh.zendesk.com/hc/en-us/articles/360000277786-RSC200351-Executing-Virtual-Machine-Operations-on-VMware-Workstation-14

Note: Since both DLLs can be freely distributed, you can download them from the above link in case you don’t have older installation of VMware Workstation.

Posted by Marcin Otorowski in Virtualization, 1 comment
26
Feb
2018

Files not installed when applying a Minor Upgrade and how to troubleshoot it

While analyzing one of customer issues reported to me, I came accross an interesting problem which – having prior knowledge how it works – would be solved in minutes, not in hours and days as it really took.

The problem

The customer reported that an MSP patch created by RayPack works fine, but not really up to his expectations. While being considerably smaller than a full MSI upgrade, the installation took a while because the previous version must have been uninstalled and installed again in the background. This is basically the idea how major upgrades are working, and the customer wanted to switch to a typical patching, which (depending on conditions) would mean going for a small update or a minor update.

We suggested to him that while usually not recommended in packaging projects, minor upgrades are different from major upgrades that they must not change ProductCode, aside of some other limitations. The customer tried it anyway and reported that our suggestion initially helped, only to report some minutes later that it actually hadn’t. The new version of product had been apparently installed (and visible in ARP), but the files were not updated – new files were still missing, binary changes were not applied etc. There were no errors during update, the msiexec exit code was also fine.

Another issue was, that after installing the patch, self-repair stopped worked for random components. Removing certain key path resources triggered repair, while for others it did not work. Weird.

Analysis + findings

Our analysis indicated that it was not actually a problem with the patch itself, but more like with the way Minor Upgrades are working, and thereof the problem could be easily reproduced by installing the second MSI containing a minor upgrade with a command line:

msiexec /i <path> REINSTALLMODE=vamus REINSTALL=all /qb

(note: vamusis non-standard, but was chosen for troubleshooting to also overwrite files in the same version). It is important to indicate that the cached MSI has to be recached from source (thus v in the reinstall mode), otherwise you obviously can’t install an MSI as minor upgrade.

We don’t do that many minor upgrades, but enough to be aware of certain limitations, including that names of MSIs must be the same (so that Product2.0.msi cannot do a minor upgrade of Product1.0.msi etc.), the feature trees must remain unchanged, some other conditions apply (more on msdn sites).

If you ever encounter a problem like that, have some time saved by this ultimate troubleshooting:
Continue reading →

Posted by Marcin Otorowski in MSI, 0 comments

About me

Senior .NET Developer / Packager. RayPack Studio Technical Product Owner.

From my Twitter