Não foi possível carregar o arquivo ou montagem ... O parâmetro está incorreto

Recentemente, conheci a seguinte exceção na solução C #:

Erro 2 Não foi possível carregar o arquivo ou assembly 'Newtonsoft.Json, Versão = 3.5.0.0, Culture = neutral, PublicKeyToken = b9a188c8922137c6' ou uma de suas dependências. O parâmetro está incorreto. (Exceção de HRESULT: 0x80070057 (E_INVALIDARG))

Isso não depende do meu código ou do nome do assembly (como Newtonsoft.Jsonneste caso).

Quando eu excluo esta dll da solução, o compilador informa sobre outra na mesma exceção. Então, suponho que algo deva ser ativado / desativado no meu PC :)

Parece que um assembly corrompido está sendo referenciado.

Limpar ambos:

1. a pasta \ bin do seu projeto

2. a pasta temporária (deve estar C:\Users\your_username\AppData\Local\Temp\Temporary ASP.NET Filesno Windows 7)

e veja se o erro ainda acontece

Dependendo se você estiver executando o X64, talvez seja necessário limpar mais alguns pontos. Apenas limpar meu diretório de usuários não foi suficiente.

1. % TEMP% \ arquivos temporários do ASP.NET
2. Arquivos C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET
3. C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Arquivos temporários do ASP.NET
4. C: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Arquivos temporários do ASP.NET
5. C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Arquivos temporários do ASP.NET

Essa lista aumentará como se você tivesse outras versões da estrutura instaladas.

Eu tive que limpar

C: /Windows/Microsoft.NET/Framework/v4.0.30319/ Arquivos ASP.NET temporários

Somente então o problema foi resolvido.

Para saber o que limpar com certeza - adicione a seguinte chave do Registro:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog (DWord set to 1).

Então você verá a saída como abaixo. Isso indica onde o asp.net está tentando carregar suas DLLs. Limpe este diretório.

LOG: This bind starts in default load context.
LOG: Using application configuration file: c:\app\AtlasAdvisor\web\web.config
LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL **file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/3c8629f7/dfa387b6/Avanade.ViddlerNet.DLL.**
LOG: Attempting download of new URL **file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/3c8629f7/dfa387b6/Avanade.ViddlerNet/Avanade.ViddlerNet.DLL**.

Limpe os arquivos de estrutura temporários do seu projeto em: -

C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ Arquivos temporários do ASP.NET \

Você também pode limpar o diretório de pacotes e permitir que o NuGet baixe novamente os pacotes ausentes

resolveu o problema para mim

Exclua todos os arquivos dessas pastas.

C: /Windows/Microsoft.NET/Framework/v4.0.30319/ Arquivos ASP.NET temporários C: /Windows/Microsoft.NET/Framework64/v4.0.30319/ Arquivos ASP.NET temporários

Obter um novo conjunto de binários do controle Source ajudou.

obrigado

Apenas limpe esta pasta: (somente Windows x64)

C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Arquivos temporários do ASP.NET

Obrigado Alex, seu segundo ponto me ajudou a consertar isso.

Parece que, a menos que você execute o visual studio como administrador no Windows 7, ele armazena seus arquivos temporários localmente, em vez de arquivos ASP: C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET.

Consulte a seguinte publicação no blog: http://www.dotnetscraps.com/dotnetscraps/post/Location-of-Temporary-ASPNET-files-in-Vista-or-Windows-7.aspx

Eu tive o mesmo problema aqui - as soluções acima não funcionaram. O problema estava com o ActionMailer. Executei os seguintes comandos de desinstalação e instalação do nuget

uninstall-package ActionMailer
install-package ActionMailer

Resolvi meus problemas, espero que ajude outra pessoa.

Isso pode acontecer ao fazer referência a DLLs de invólucro COM. No seu projeto do Visual Studio, em Referências, selecione as DLLs do invólucro COM que estão sendo referenciadas e verifique se eles têm os seguintes valores de propriedade: "Incorporar tipos de interoperabilidade": Falso e "Versão específica": Falso.

Acabei de excluir os dados temporários do aplicativo desse caminho

C:/Windows/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files

Resolução de problemas

Vejo muitos técnicos publicados sobre a limpeza de diretórios temporários de tempo de execução do ASP .Net pertencentes a cada estrutura .Net hospedada em sua máquina, como neste resposta. Mas acredito que devemos conhecer a logística clara de por que precisamos limpar cegamente todos os diretórios de trabalho temporários de todas as estruturas .Net. Segundo mim, não deveria ser o caso.

Meu conselho seria que você deveria tentar uma abordagem de limpeza de diretório pontiaguda para resolver esse problema. Como você saberia qual diretório limpar?

1. Vá para o IIS e clique com o botão direito do mouse no nó do site no painel de navegação esquerdo para abrir o menu de contexto. No menu de contexto, aponte para Manage Application-> Advanced Settings...para abrir a Advanced Settingsjanela.
2. Verifique o pool de aplicativos ao qual seu site está atribuído. No meu caso, é DefaultAppPoolcomo mostrado abaixo:

3. Agora vá para o Application Poolsnó na barra de navegação esquerda no IIS. Agora verifique se a versão .Net CLR está sendo executada pelo seu pool de aplicativos. No meu caso, é a v4.0, como mostrado abaixo:

Como a versão do CLR hospedada pelo meu pool de aplicativos é a v4.0, limpei apenas os arquivos temporários da pasta pertencentes ao ASP .NET v4.0 apenas como abaixo:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files

E é isso. Meu problema foi resolvido.

Lição aprendida : isso é indicativo do fato de que todos os arquivos temporários usados ​​pelo seu site não estão espalhados por vários diretórios, mas são ao mesmo tempo referenciados pelo seu pool de aplicativos. Então, você precisa limpar apenas essa pasta específica.

A limpeza dos arquivos C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ Temporary ASP.NET funcionou para mim. Pensando em automatizar o processo de exclusão para evitar o problema no futuro.

Se você estiver usando o Data Tools do SQL Server 2012, que usa o shell do VS2010 em 1 de maio de 2013, verifique as configurações do Gerenciador de Configurações. Uma alteração no nome do servidor de Fluxo de trabalho para xCPWorkflow foi suficiente para produzir exatamente o mesmo. O parâmetro está incorreto (exceção de HRESULT: 0x80070057 (E_INVALIDARG)) .

Você pode limpar, criar ou reconstruir seu aplicativo ou simplesmente excluir arquivos ASP.NET temporários em C: \ Users \ YOUR USERNAME \ AppData \ Local \ Temp

Isso funciona como mágica. No meu caso, tive um problema de ligação de assembly dizendo Não foi possível carregar o arquivo bla bla bla

você também pode ver a solução 2 como http://www.codeproject.com/Articles/663453/Understanding-Clean-Build-and-Rebuild-in-Visual-St

Eu tive esse problema ao fazer o controlador no MVC. Eu mudei a versão do framework .net. O problema foi resolvido

O problema está relacionado à versão de tempo de execução .Net de uma biblioteca de classes referenciada (referências expandidas, selecione a biblioteca e verifique a "Versão de tempo de execução". Eu tive um problema com o Antlr3.Runtime, depois de atualizar meu projeto do visual studio para a v4.5. usei o NuGet para desinstalar o Microsoft ASP.NET Web Optimization Framework (devido a uma cadeia de dependências que me impediram de desinstalar o Antlr3 diretamente)

Em seguida, usei o NuGet para reinstalar o Microsoft ASP.NET Web Optimization Framework. Isso reinstalou as versões corretas de tempo de execução.

No meu caso, eu queria compilar uma DLL visível do COM. O problema era que uma versão mais antiga desta DLL estava localizada aqui:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE

Assim, o Visual Studio carregou essa versão em vez da recém-compilada, enquanto tentava registrá-la.

Limpar todos os arquivos da pasta temporária (pasta C: \ Users \ user_name \ AppData \ Local \ Temp \ Temporary ASP.NET Files \ project)

Às vezes, você também precisa limpar esta pasta: C: \ Windows \ Temp \ Temporary ASP.NET

Eu enfrentei o mesmo erro porque o aplicativo não encontrou estruturas dependentes na C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\pasta. Acabei de reparar meu Visual Studio, que adicionou a estrutura necessária no local acima e está funcionando bem.

No meu caso, alterar o número da porta IISExpress nas propriedades do meu projeto resolveu o problema.

Se alguém por aí estiver usando o conjunto de ferramentas WiX, descobri que meu projeto de instalador tinha uma referência a um projeto antigo que havia sido removido recentemente da solução. Demorei um pouco para perceber, uma vez que havia vários projetos na solução que eu estava tentando criar e a mensagem não indicava qual projeto estava falhando na criação (e estava limpo, o que também estava falhando).

Eu tive usuários do Siemens Teamcenter 10 Client para Microsoft Office recebendo o mesmo erro sobre uma DLL diferente. Nenhuma das outras respostas funcionou. A solução foi excluir as pastas no

C:\Users\%username%\AppData\Local\assembly\

Eu tive o problema semelhante ao abrir o gerenciador de pacotes Nuget, removi todos os arquivos temporários e construí o projeto, funcionou bem.