Visual Studio 2017 Installation "A product matching the following parameters cannot be found"

          While installating Visual Studio 2017 Community update I've got a blue screen. The installation became corrupt and I had to reinstall. The moment I've launched the reinstall I started getting errors one after another.

• while starting the installer:
  "A product matching the following parameters cannot be found:
  channelId: VisualStudio15.Release
  productId: Microsoft.VisualStudio.Product.Community"
• while choosing a package to install:
  "Error: Sorry installation failed. Please Try Again.

I've gone through the following steps, which helped me in resolving this issue:

• uninstalled Visual Studio (and other Visual Studio installations)
• run C:\Program Files (x86)\Microsoft Visual Studio\Installer\InstallCleanup.exe -full"
• removed all the "C:\Program Files (x86)\Microsoft Visual Studio" folders
• removed "C:\Program Data\Microsoft\Visual Studio\ folder
• restarted Windows

Installation run perfectly fine afterwards - I'm not sure thought which of these steps were required. I suppose the only thing I could have tried was not removing all Visual Studio installations before trying the other options.

UPDATE:
Also worth mentioning, I had to do a "Repair" after that first successful installation due to issues with launching "Extensions and Updates". Check, if it works for you after you've managed to install VS.

Migrating to .net core

     I haven't seen many such posts elsewhere and thought about doing a small write-up on my latest work with .net core. I had a couple of approaches to .net core, all stopped due to different issues with missing libraries and certain volatility in development. I was one of many waiting for version 2.0 to arrive to take another dive into core.

Here's the list of little things to remember about and potential issues which one can stumble upon when porting an app to .net core. I won't be going into details of each, just some food for thought:

- ConfigurationManager is gone - library that comes with .core brings IOptions<T> interface, which allows for mapping settings.json file to POCO classes. All places, which use ConfigurationManager will have to get rewritten with either a cusom configuration framework or IOptions<T>.

Advantages:

1. IOptions can be easily injected into classes using the DI scaffolding available out of the box
2. Given it uses POCOs with nicely mapped properties along with lists and dictionaries, all strongly typed
3. It reloads the values on change in the settings file

Disadvantages:

1. We are bound to the IOptions interface, which seems to be an unneeded dependency
2. Application reads the underlaying POCO when IOptions value is accessed - which means any errors will be delayed until that time
3. In case we don't need the reloading functionality IOptions doesn't seem that useful, for the extra boilerplate it brings to the table

UPDATE:

You can actually download the following nuget package to get ConfigurationManager back:

https://www.nuget.org/packages/System.Configuration.ConfigurationManager/

- DirectoryServices namespace has not been migrated - this library is required for LDAP connectivity. It is quite often used in enterpraise ecosystems and might be a blocker for many to be able to move to .net core.

Potential solutions:

1. I've checked the only open source LDAP solution, which supports .net standard: https://github.com/dsbenghe/Novell.Directory.Ldap.NETStandard                                            It's basic functionality works. Unfortunately it does not support SSL which is a must when you want to have a certficate based authentication.
2. Write a separate proxy API for LDAP connectivity in C# or another language to be called from your .net core project - whichever is easier to route your LDAP calls.

Here's discussion on the work being done and migration of this feature to .net core in the future:

https://github.com/dotnet/corefx/issues/2089

- Windows based functionalities are not available - I know this sounds like a no-brainer, but it took a bit before it dawned on me :). Anyone who is planning to port should take a serious look through the code base. Check if there are no windows registry usages hiding somewhere in the plumbing of the app.

- Rijndael encryption with 256-bit block size is not supported - in case your code uses RijndaelManaged to perform encryption with 256-bit block size, you'll have to find another implementation - such a BouncyCastle.

- IHttpModule and IHttpHandler pipeline changed into .net core middleware - it has slightly changed how HTTP request processing pipeline works in .net core. There are no IHttpModule or IHttpHandler interfaces. The new guy in town is called .net core middleware. It's pretty easy to migrate modules to the new middleware. On top of it the DI scaffolding in .net core allows to inject dependencies to both constructor (singletons only given lifetime of middleware) and into the Invoke method - which is our request handling method. Read more below:
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/middleware?tabs=aspnetcore2x

- Lazy Loading and edmx missing from EF Core - lazy loading hasn't been implemented yet in Entity Framework for .net core along with any feature based on .edmx.
Why lazy loading is not always the best idea can be read here in detail:
https://ardalis.com/avoid-lazy-loading-entities-in-asp-net-applications
It still is an important tool in any EF's user toolbelt, discussion on it and an open source alternative can be found here:
https://github.com/aspnet/EntityFrameworkCore/issues/3797

UPDATE:
In addition to missing lazy loading, at least for now certain functionalities are not available through DataAnnotations or convention and require explicit entry in code. Among others composite keys. Hence when finding some features missing check, whether some other EF configuration approach is available.