Não foi possível carregar o tipo do erro de montagem

Escrevi o seguinte teste simples ao tentar aprender a Interface Fluente de Castle Windsor:

using NUnit.Framework;
using Castle.Windsor;
using System.Collections;
using Castle.MicroKernel.Registration;

namespace WindsorSample {
    public class MyComponent : IMyComponent {
        public MyComponent(int start_at) {
            this.Value = start_at;
        }
        public int Value { get; private set; }
    } 
    public interface IMyComponent {
        int Value { get; }
    }

    [TestFixture]
    public class ConcreteImplFixture {
        [Test]
        public void ResolvingConcreteImplShouldInitialiseValue() {
            IWindsorContainer container = new WindsorContainer();
            container.Register(Component.For<IMyComponent>().ImplementedBy<MyComponent>().Parameters(Parameter.ForKey("start_at").Eq("1")));
            IMyComponent resolvedComp = container.Resolve<IMyComponent>();
            Assert.AreEqual(resolvedComp.Value, 1); 
        }
    }
}

Quando executo o teste através do TestDriven.NET, obtenho o seguinte erro:

System.TypeLoadException : Could not load type 'Castle.MicroKernel.Registration.IRegistration' from assembly 'Castle.MicroKernel, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc'.
at WindsorSample.ConcreteImplFixture.ResolvingConcreteImplShouldInitialiseValue()

Quando executo o teste através da NUnit GUI, obtenho:

WindsorSample.ConcreteImplFixture.ResolvingConcreteImplShouldInitialiseValue:
System.IO.FileNotFoundException : Could not load file or assembly 'Castle.Windsor, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' or one of its dependencies. The system cannot find the file specified.

Se eu abrir a Assembléia que estou referenciando no Reflector, posso ver suas informações:

Castle.MicroKernel, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc

e que ele definitivamente contém Castle.MicroKernel.Registration.IRegistration

O que poderia estar acontecendo?

Devo mencionar que os binários são retirados da versão mais recente do Castle, embora eu nunca tenha trabalhado com o nant, então não me incomodei em compilar novamente a partir do código-fonte e apenas peguei os arquivos no diretório bin. Devo também salientar que meu projeto é compilado sem nenhum problema.

A montagem está no Global Assembly Cache (GAC) ou em algum lugar que possa estar substituindo a montagem que você acha que está sendo carregada? Geralmente, isso é o resultado de um assembly incorreto sendo carregado. Para mim, isso significa que normalmente tenho algo no GAC substituindo a versão que tenho no bin / Debug.

Se você tiver um projeto referenciando outro projeto (como um tipo de 'Aplicativo do Windows' referenciando uma 'Biblioteca de Classes') e ambos tiverem o mesmo nome de Assembly, você receberá esse erro. Você pode nomear fortemente o projeto referenciado ou (melhor ainda) renomear a montagem do projeto de referência (na guia 'Aplicativo' das propriedades do projeto no VS).

A solução para isso para mim não foi mencionada acima, então pensei em adicionar minha resposta à cauda longa ...

Acabei tendo uma referência antiga para uma classe ( HttpHandlerweb) no web.config que não estava mais sendo usada (e não era mais uma referência válida). Por alguma razão, ele foi ignorado durante a execução no Studio (ou talvez eu ainda tenha essa classe acessível na minha configuração de desenvolvedor?) E, portanto, só recebi esse erro quando tentei implantar no IIS. Eu procurei no nome do assembly em web.config, removi a referência do manipulador não utilizado, então esse erro desapareceu e tudo funciona muito bem. Espero que isso ajude outra pessoa.

Eu tive o mesmo problema e, para mim, não tinha nada a ver com namespace ou nomeação de projetos.

Mas, como vários usuários sugeriram, isso tinha a ver com uma montagem antiga ainda sendo referenciada.

Eu recomendo excluir todas as pastas "bin" / binárias de todos os projetos e recriar toda a solução. Isso acabou com todos os assemblies potencialmente desatualizados e, depois disso, o MEF exportou todos os meus plugins sem problemas.

Eu estava recebendo esse erro e nada que encontrei no StackOverflow ou em outro lugar o resolveu, mas a resposta do bmoeskau a esta pergunta me indicou a direção certa para a correção, que ainda não foi mencionada como resposta. Minha resposta não está estritamente relacionada à pergunta original, mas a estou postando aqui, supondo que alguém com esse problema encontre o caminho para pesquisar no Google ou algo semelhante (como eu daqui a um mês, quando isso me morder novamente) , arg!).

Minha montagem está no GAC, portanto, teoricamente, existe apenas uma versão da montagem disponível. Exceto que o IIS é útil para armazenar em cache a versão antiga e me fornecer esse erro. Acabei de alterar, reconstruir e reinstalar a montagem no GAC. Uma solução possível é usar o Gerenciador de tarefas para matar o w3wp.exe . Isso força o IIS a reler o assembly do GAC: problema resolvido.

A versão = 1.0.3.0 indica o Castle RC3, no entanto, a interface fluente foi desenvolvida alguns meses após o lançamento do RC3. Portanto, parece que você tem um problema de versão. Talvez você tenha o Castle RC3 registrado no GAC e esteja usando esse ...

Eu recebo isso de vez em quando e sempre foi bom ter a montagem no GAC

Se esse erro causado pela alteração do espaço para nome, verifique se a pasta desse projeto foi renomeada com o mesmo nome e feche o VS.NET Edite o projeto com o problema no Bloco de Notas e substitua os nós

"RootNamespace> New_Name_Of_Folder_Of_Your_Project_Namespace" RootNamespace> "AssemblyName> New_Name_Of_Folder_Of_Your_Project_Namespace" AssemblyName>

A exclusão do meu arquivo .pdb para a dll resolveu esse problema para mim. Acho que tem algo a ver com o fato de que a dll foi criada usando o ILMerge.

Quando encontro esse problema, acho a ferramenta FUSLOGVW muito útil. Ele está verificando informações de ligação de montagem e as registra para você. Às vezes, as bibliotecas estão ausentes, às vezes o GAC tem versões diferentes que estão sendo carregadas. Às vezes, a plataforma de bibliotecas referenciadas está causando os problemas. Essa ferramenta deixa claro como as ligações das dependências estão sendo resolvidas e isso pode realmente ajudá-lo a investigar / depurar seu problema.

Visualizador de log do Fusion / fuslogvw / Visualizador de log de ligação de montagem. Confira mais / faça o download aqui: http://msdn.microsoft.com/en-us/library/e74a18c4.aspx .

Eu tive esse problema depois de fatorar um nome de classe:
Could not load type 'Namspace.OldClassName' from assembly 'Assembly name...'.

Parar o IIS e excluir o conteúdo Temporary ASP.NET Filescorrigiu para mim.

Dependendo do seu projeto (32/64 bits, versão .net, etc), o correto Temporary ASP.NET Filesdifere:

• 64 Bit
  %systemroot%\Microsoft.NET\Framework64\{.netversion}\Temporary ASP.NET Files\
• 32 Bit
  %systemroot%\Microsoft.NET\Framework\{.netversion}\Temporary ASP.NET Files\
• Na minha máquina de desenvolvimento era (porque talvez seja o IIS Express?)
  %temp%\Temporary ASP.NET Files

Talvez não seja tão provável, mas para mim foi causado pelo meu aplicativo tentar carregar uma biblioteca com o mesmo nome de assembly (xxx.exe carregando xxx.dll).

Basta encontrar isso com outra causa:

executando testes de unidade no modo de liberação, mas a biblioteca que está sendo carregada era a versão do modo de depuração que não havia sido atualizada

Outra solução: DLLs antigas apontando uma para a outra e armazenadas em cache pelo Visual Studio no

C:\Users\[yourname]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies

Saia do VS, exclua tudo nesta pasta e Bob é seu tio.

Eu tive o mesmo problema. Acabei de resolver isso atualizando o assembly via GAC.

Para usar gacutil em uma máquina de desenvolvimento acesse: Start -> programs -> Microsoft Visual studio 2010 -> Visual Studio Tools -> Visual Studio Command Prompt (2010).

Eu usei esses comandos para desinstalar e reinstalar, respectivamente.

gacutil /u myDLL

gacutil /i "C:\Program Files\Custom\mydllname.dll"

Nota: eu não desinstalei minha dll no meu caso, apenas atualizei a dll com o caminho atual.

Eu me deparei com esse cenário ao tentar carregar um tipo (via reflexão) em um assembly que foi criado com uma versão diferente de uma referência comum ao aplicativo em que esse erro apareceu.

Como tenho certeza de que o tipo não foi alterado nas duas versões do assembly, acabei criando um resolvedor de assembly personalizado que mapeia o assembly ausente para o que meu aplicativo já carregou. A maneira mais simples é adicionar um construtor estático à classe do programa da seguinte maneira:

using System.Reflection
static Program()
{
    AppDomain.CurrentDomain.AssemblyResolve += (sender, e) => {
        AssemblyName requestedName = new AssemblyName(e.Name);

        if (requestedName.Name == "<AssemblyName>")
        {
            // Load assembly from startup path
            return Assembly.LoadFile($"{Application.StartupPath}\\<AssemblyName>.dll");
        }
        else
        {
            return null;
        }
    };
}

Obviamente, isso pressupõe que o Assembly esteja localizado no caminho de inicialização do aplicativo e possa ser facilmente adaptado.

Basta encontrar isso com outra causa:

Eu estava usando um assembly mesclado criado com o ILRepack. A montagem da qual você está consultando os tipos deve ser a primeira passada para o ILRepack ou seus tipos não estarão disponíveis.

Você pode resolver isso com redirecionamentos de ligação em * .config. http://blogs.msdn.com/b/dougste/archive/2006/09/05/741329.aspx tem uma boa discussão sobre o uso de componentes .net mais antigos em estruturas mais novas. http://msdn.microsoft.com/en-us/library/eftw1fys(vs.71).aspx

Isso geralmente acontece quando você tem uma versão do seu assembly implantada no GAC, mas não foi atualizada com as novas classes que você pode ter adicionado ao assembly no seu IDE. Portanto, verifique se a montagem no GAC está atualizada com as alterações que você pode ter feito no seu projeto.

Por exemplo, se você possui uma Biblioteca de Classes Comum e nessa Biblioteca de Classes você tem o tipo Common.ClassA e implanta-o no GAC com forte nome. Você vem mais tarde e adiciona outro tipo chamado Common.ClassB e executa seu código no IDE sem antes implantar as alterações feitas no GAC of Common com o tipo Common.ClassB recém-adicionado.

Eu recebi o mesmo erro depois de atualizar uma dll referenciada em um projeto executável de área de trabalho. O problema era que as pessoas mencionadas aqui relacionavam uma referência antiga e simples de corrigir, mas não foram mencionadas aqui, então pensei que poderia economizar o tempo de outras pessoas.

De qualquer forma, atualizei a DLL A e recebi o erro de outra DLL referenciada, vamos chamá-la de B aqui, onde a DLL A tem uma referência à DLL B.

A atualização da DLL B corrigiu o problema.

Adicionando sua DLL ao GAC (cache global de assemblies)

Prompt de Comando do Visual Studio => Executar como Administrador

gacutil / i "caminho do arquivo dll"

Você pode ver o conjunto adicionado C: \ Windows \ system32 \

Ele também resolverá a DLL ausente ou "Não foi possível carregar o arquivo ou o conjunto" na tarefa de script SSIS

Ocorreu um problema semelhante no Visual Studio 2017 usando o MSTest como estrutura de teste. Eu estava recebendo exceções System.TypeLoadException ao executar alguns (não todos) testes de unidade, mas esses testes de unidade passavam quando depurados. Eu finalmente fiz o seguinte que resolveu o problema:

1. Abra o arquivo Local.testsettings na solução
2. Vá para as configurações de "Teste de unidade"
3. Desmarque a opção "Usar o contexto de carregamento para montagens no diretório de teste". caixa de seleção

Após executar essas etapas, todos os testes de unidade começaram a passar quando executados.

Eu experimentei o mesmo que acima, depois de remover a assinatura de montagens na solução. Os projetos não seriam construídos.

Descobri que um dos projetos referenciava o pacote StrongNamer NuGet, que modifica o processo de criação e tenta assinar pacotes Nuget não assinados.

Depois de remover o pacote StrongNamer, consegui construir o projeto novamente sem assinar / nomear fortemente os assemblies.

Acabei de resolver isso executando o comando iisreset usando o prompt de comando ... Sempre a primeira coisa que faço quando recebo esses erros.