Como instalar a implementação padrão do IConstructorSelector para ser usada em todo e qualquer registro

Não há uma maneira realmente boa de fazer isso.

Grande parte do desafio está na combinação da sintaxe do construtor/retornos de chamada usados, bem como na natureza dinâmica das coisas que o Autofac fornece com conceitos como fontes de registro.

Quando você registra coisas ( comoRegisterType<T>() ), ele adiciona uma única função de retorno de chamada ao ContainerBuilder. O conjunto geral de funções de registro encadeadas é executado no final, duranteBuild() É uma espécie de construção de uma cadeia de middleware de retorno de chamada para retorno de chamada para retorno de chamada que acaba construindo um registro de objeto completo. Não há um lugar real para "interceptá-los globalmente".

Apresentar algo "global" tem algumas implicações que não são muito fáceis de abordar, e é por isso que algo assim não existe.

• Você pode registrar coisas novas em escopos de tempo de vida filho. Todos eles devem usar o mesmo seletor de construtor global? E se você quiser substituir o seletor de construtor apenas para esse escopo de tempo de vida? Se você substituir o seletor no escopo de tempo de vida, isso também leva em conta todos os registros que foram registrados em um escopo de tempo de vida pai ou isso agora altera esses registros pais?
• Como lidamos com coisas como fontes de registro que adicionam registros dinamicamente por meio de, digamos, varredura de assembly? Elas obedecem ao seletor global? Como aplicamos isso em fontes personalizadas que as pessoas escrevem?
• Se, em vez disso, permitíssemos que o middleware modificasse o localizador ou seletor do construtor no momento da resolução (que é um possível ponto de conexão para algo assim), como isso começaria a afetar coisas como singletons ou entidades de escopo de instância por tempo de vida?
• Como fornecemos suporte/observabilidade para ajudar as pessoas em grandes projetos a solucionar problemas quando isso dá errado? Alguém em algum lugar definiu um seletor de construtor personalizado, outra pessoa não sabe onde está esse código, agora todos os registros estão quebrados e "Autofac está quebrado, o que vocês, caras da Autofac, fizeram?"

Colocar um conjunto rápido de opções no ContainerBuilderé, claramente, uma coisa muito fácil de fazer. Só que o efeito cascata de "mudar o comportamento global" traz uma tonelada com ele, então não fizemos isso.

Dito isso, se isso for algo interessante, eu o encorajaria a abrir um problema e propô-lo . Se fizer isso, certifique-se de incluir o design proposto para todas as pequenas partes de longo alcance, como mencionei. A equipe é pequena e projetar novos recursos de linguagem como esse requer que a comunidade contribua com o trabalho braçal. (Temos um problema para um globalIPropertySelector com uma solicitação semelhante, mas não há design e não há uma ótima maneira de lidar com isso.)

Adendo: Embora eu não possa iterar sobre soluções, direi o seguinte:

Com base no objetivo de forçar um construtor específico devido a essa migração do MEF, se fosse eu, eu iria e...

1. Encontre todos os objetos que têm mais do que apenas um construtor de 0 parâmetros e múltiplos parâmetros. Esses serão aqueles em que você acha que precisa mirar em alguma coisa específica. Pode não ser tanto. Você pode estar tentando resolver um problema em que há apenas 3 classes ofensivas. Se for esse o caso, registre o seletor em linha. Exceto isso...
2. Ou remova os construtores que você não quer que o Autofac considere ou torne-os internos. Em um sistema DI padrão, você realmente tenta evitar ter um monte de construtores especificamente para contornar esse problema de seleção.

Entendo que isso pode estar banalizando o problema, mas migrar do MEF não dá trabalho nenhum, assim como migrar do WCF para o ASP.NET Core não dá trabalho nenhum.

Mas como eu disse, se fosse EU, é assim que eu faria.