I created a .net fx based asp.net web api 2 project, with which i attempted to use MS Dependency injection and MS logging assemblies from Microsoft.Extensions components. It works actually with non dotnet core based projects, providing Dependency injections and logging framework with abstractions. Locally and when we use Visual studio (ver 2017 in my case), it works, deploys if needed and runs successfully.
When we use MSBUILD though, it fails. I have another web api 2 project that is not using the DI and logging through MS.extns and it builds successfully. I have no clue to resolve the conflicts i am facing. As i try to remove the conflicting assemblies, it steps up to the Injection and logging abstraction libraries to be removed.
I am also using EF 6 in my project. The conflict started with System.ComponentModel.Annotations. My failed build log error lines are below.
both are web api 2 (non dotnet core) 1. successful build = .net fx 4.6.2, EF 6, DI using Unity. (didnt implement logging at the time) 2. failed build project = .net fx 4.6.2, EF 6, DI using MS.Extns.DI and logging using MS.Extns.Logging.
CSC : error CS1703: Multiple assemblies with equivalent identity have been imported: 'C:\AK\Api\PMApi\packages\System.ComponentModel.Annotations.4.5.0\lib\net461\System.ComponentModel.Annotations.dll' and 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.2\Facades\System.ComponentModel.Annotations.dll'. Remove one of the duplicate references. [C:\AK\Api\PMApi\PM.Data\PM.Data.csproj]
Done Building Project "C:\AK\Api\PMApi\PM.Data\PM.Data.csproj" (default targets) -- FAILED.
Done Building Project "C:\AK\Api\PMApi\PM.BL\PM.BL.csproj" (default targets) -- FAILED.
Done Building Project "C:\AK\Api\PMApi\PM.Api\PM.Api.csproj" (default targets) -- FAILED.
Done Building Project "C:\AK\Api\PMApi\ProjectManApi.sln" (default targets) -- FAILED.
Build FAILED.
"C:\AK\Api\PMApi\ProjectManApi.sln" (default target) (1) ->
"C:\AK\Api\PMApi\PM.Api\PM.Api.csproj" (default target) (2) ->
"C:\AK\Api\PMApi\PM.BL\PM.BL.csproj" (default target) (3) ->
"C:\AK\Api\PMApi\PM.Data\PM.Data.csproj" (default target) (4) ->
(CoreCompile target) ->
CSC : error CS1703: Multiple assemblies with equivalent identity have been imported: 'C:\AK\Api\PMApi\packages\System.ComponentModel.Annotations.4.5.0\lib\net461\System.ComponentModel.Annotations.dll' and 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.2\Facades\System.ComponentModel.Annotations.dll'. Remove one of the duplicate references. [C:\AK\Api\PMApi\PM.Data\PM.Data.csproj]
0 Warning(s)
1 Error(s)
Please help me, as i wanted to attempt DI and Logging framework using MS extns and it works cool while testing and running. As far as the msbuild goes, which i am using to setup the Continuous Integration using Jenkins/Team city as my own instance, i need MSBUILD only to build/test/deploy.
I need to know if this DI and logging from MS.Extns will not work with non dotnet core, and that i have to switch to use different DI framework. because, i have completed my api, tested locally and everything works fine.
preferrably, i wish to use these with proper advise on how to get rid of this conflict from MSBUILD.
Update 1: All the Nuget pkgs are latest and upto date. Also, the conflict on the Annotations is throwing in all the projects irrespective of proj that is for EF. When i have the nuget to give me libraries, why msbuild will also need to lookup Microsoft reference assemblies path in the machine drive?
Update 2: the conflict comes from Microsoft.Extensions.Logging - Microsoft.Extensions.Options assemblies which references to System.ComponentModel.Annotations. The Nuget version tries to download 4.5.1 i think, while the Microsoft Common assemblies path seems to have 4.6.x or higher which for some reason, the Msbuild refers to and end up in conflict.
I have my solution in github if its worth looking into on where the issue is. Github link Thanks
For what its worth, i moved on to use .net core 2.1 as a solution to have my Web API. I created a new web api solution on .net Core 2.1 version and thus solved my need.
Long story short: .net Core 2.x Web API solution with logging framework extensions and its own IOC framework does all.
Short story long: Few things to note upon my personal experience while moving from .net web api to .net Core based Web API:
Assembly size (build size) was way low. probably because, the .net core has its core assemblies as run time assemblies and hence the desired code output assemblies turns out to be lower. This can be ideal when you want to ship or host on cloud provided you have the .net core runtime installed. Lots of documentation indeed talks about various options on this topic, like if you dont want this, you have the respective assemblies loaded along with the application assembly.
build and publish is simpler: using the dotnet command with parameters for output path and configuration type are simplest to start with. Again, MS has extensive documentation on how we can expand this (to make it more complex, custom driven or using MSBUILD templates) but for most need, the simple solution is affordable in current platforms.
We can use any other IOC but MS own IOC is not just simple to implement, but bound with its own core implementation. There are other IOCs that we can use to extend with MS extensions but that again, purely from my perspective is upto how we can make it more complex (on need basis) but simpler solutions and relying on other standards infrastructure given they are compatible with .net core assemblies, we are decent enough to use their own extensions for IOC .
Logging - comes with well known logging frameworks now provided extensions to .net core MS logging framework. I prefer Nlog, and Serilog but its an open choice whichever is compatible wtih .net core MS Extensions for Logging.
CORS - has to be dealt in a little different way and carefully crafted if used across apps/domains or mix.
I am open and happy to hear feedback to my points but again, these are my personal hands on experience that i have shared as pointers i noticed as unique differences when moving from .net Web API. (migrating/rewriting api base framework)