Tuesday, August 2, 2022

CSC : warning CS8032: An instance of analyzer RoslynBasics.MySourceGenerator cannot be created from. Could not load file or assembly 'Microsoft.CodeAnalysis, Version=4.2.0.0,

When we are developing .Net Compiler Platform (Roslyn)¹ related code and using it in Visual Studio there are chances of getting the below exception when compiling in Visual Studio 2022.

In my scenario, I got this exception when developing a SourceGenerator².

CSC : warning CS8032: An instance of analyzer RoslynBasics.MySourceGenerator cannot be created from C:\..\RoslynBasics\bin\Debug\netstandard2.0\RoslynBasics.dll : Could not load file or assembly 'Microsoft.CodeAnalysis, Version=4.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified..

There are many resolutions available on google. Below is the one that worked for me.
Downgrade the Microsoft.CodeAnalysis to 4.1.00

Root cause

Though the latest version is 4.2.0.0 but the Visual Studio 2022 (17.1.1) is unaware of it. Hence it failed. We can check the version of Microsoft.CodeAnalysis that Visual Studio uses in the below folder location.

C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\Roslyn

The location of Visual Studio 2019 and other versions is different.

Solution

The right solution can be to upgrade Visual Studio to 17.2.x. 

Once VS 2022 is upgraded the nuget 4.2.0.0 started working fine. 

Above is the new dll version after the upgrade of Visual Studio

References


Tuesday, July 26, 2022

Modernize legacy .Net Framework WebApi apps with .Net Core ILogger & DI

This post is advised to read after the previous post about modernizing the .Net Framework console app to use .Net Core Programming model without changing the runtime. It helps to slowly migrate large monolith .Net Framework apps into .Net.

This post is about slowly migrating legacy WebAPI applications in the same way. ie adding DI using ServiceCollection and ILogger without changing the .Net Framework runtime.

Sample source code

This time there is no video tutorial. Let us look at the actual code itself.

Below goes the areas that need to be changed to get dependency injection from the Controller classes themselves.

Creating the ServiceCollection

This is obviously the first step in doing the DI.

Hope the code is explanatory if we have some basic idea about the .Net Core programming model. The Get() returns the ServiceProvider after configuring ServiceCollection.

Overriding DependencyResolver

It's easy to see the code first.

We just added our own DependencyResolver. Next, let us see what is in that new resolver class.

This facilitates the creation of objects as and when asked by the ASP.Net WebAPI framework.

ILogger Support

Nothing special to be done. The ConfigureServices() in ServiceProviderFactory class does it.

References


Tuesday, July 19, 2022

Modernize legacy .Net Framework Console apps with .Net Core ILogger & DI

There are already lot of  tools and techniques to modernize .Net Framework applications by migrating to .Net. There is a question what modernization we are getting by changing the runtime without changing the architecture or at the minimum UI? That question we are keeping aside and taking the requirement of modernizing a decade old legacy monolith .Net Framework app having a million lines of code. 

Here the tools can do limited things. That app may be not at all having the concept of Dependency Injection, lot of COM components used and built on top of WCF and old remoting. On top of that if there is no budget to reserve a release just to modernize.

None of the quick techniques works there. One strategy could be to modernize it part by part. At least to start with we can start refactoring to the Dependency Injection using ServiceCollection and ILogger usage similar to .Net Core and .Net Application. 

The question may come can we use these .Net Core programming model in .Net Framework apps. The answer is yes if we are in .Net 4.8 or a version that supports the nugets. We should really thanks to the concept of .Net Standard and design of modern .Net as modular using nuget packages.

One such mechanism is explained in the below video. 

We can still stay in .Net Framework and we can use .Net Core Programming model such as Dependency Injection and ILogger usage.


  

Source code is available in GitHub.