Eliminating assembly binding redirects when targeting the .Net framework

By -

We have a solution with 100+ projects (part of a big ugly .Net Framework Monolith app). Now we are pushing to move as much code as possible as NuGet packages to our internal repo. But now we are in a dependency hell, because even though all of our code is unsigned, most of the 3rd party NuGets are signed. As well as all the Microsoft packages.

This hell got worse since we migrated from packages.config to PackageReference, because many dependencies became implicit (being transitive). On one hand we want to use PackageReference, because:

  1. It is a step closer to moving to SDK style projects, where possible.
  2. Precisely, because it shows what we use without cluttering the project with transitive deps.
  3. It is the future, right?

But on the other hand it is hellish to sort through all these binding redirects. And the worst thing - it is not consistent from msbuild to VS IDE, see Why does console build generate radically different project.assets.json than that generated with VS IDE build?

I want to get rid of them once and for all. My idea is:

  1. Suppress all the warnings related to binding redirects - MSB3277 and MSB3247
  2. Remove them from all the config files
  3. Resolve assemblies at runtime with a dedicated code

I wonder if anyone has tried this approach. Cannot be that we are the only ones that are struggling with the binding redirects, this device of torture inflicted upon us undoubtfully for the sin of programming .Net rather than Java.

I have a concrete question - has anyone succeeded in replacing all the config time assembly binding redirects with a logic at runtime? I want to suppress all of the binding redirect related warnings and forget about them once and for all while staying in .Net Framework (not Core) realm.



from Recent Questions - Stack Overflow https://ift.tt/2I3WV1S
https://ift.tt/eA8V8J

Comments

Post a Comment

Popular posts from this blog

Spring Elasticsearch Operations

By -
Elasticsearch Operations Spring Data Elasticsearch uses two interfaces to define the operations that can be called against an Elasticsearch index. These are ElasticsearchOperations and ReactiveElasticsearchOperations. Whereas the first is used with the classic synchronous implementations, the second one uses reactive infrastructure. The default implementations of the interfaces offer: Read/Write mapping support for domain types. A rich query and criteria api. Resource management and Exception translation. ElasticsearchTemplate The ElasticsearchTemplate is an implementation of the ElasticsearchOperations interface using the Transport Client. @Configuration public class TransportClientConfig extends ElasticsearchConfigurationSupport {   @Bean   public Client elasticsearchClient() throws UnknownHostException {                      Settings settings = Settings.builder().put("cluster.name", "elasticsearch")....
Read more

Today Walkin 14th-Sept

By -
Image
14th Sept 2017 ( GO Through all List) Read Walkin details properly , Try to call company before attending if possible !!! ==================================== 1. Myntra through fresherworld (Call Based , Venue shared to shortlisted candidates) _____________________________ 2. Magna : Hiring for Client Harman : C++
Read more

Object oriented programming concepts (OOPs)

By -
Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects". Re-usability is the main concept of Oops. There are few major principles of object-oriented paradigm. If any programming Language supports this principles that programming language called Object-oriented programming. Below are object oriented programming concepts : 1. Object        Read More about Object     http://theprogrammersfirst.blogspot.in/2016/07/java-object-concept.html
Read more