Ao executar um projeto de aplicativo da Web, em momentos aparentemente aleatórios, uma página pode falhar com um erro CS0433: o tipo existe em várias DLLs. As DLLs são todas as DLLs geradas que residem no diretório "Arquivos ASP.NET Temporários".
Ao executar um projeto de aplicativo da Web, em momentos aparentemente aleatórios, uma página pode falhar com um erro CS0433: o tipo existe em várias DLLs. As DLLs são todas as DLLs geradas que residem no diretório "Arquivos ASP.NET Temporários".
Respostas:
Adicione o atributo batch = "false" ao elemento "compilation" do arquivo web.config.
Esse problema ocorre devido à maneira como o ASP.NET 2.0 usa as referências do aplicativo e a estrutura da pasta do aplicativo para compilar o aplicativo. Se a propriedade batch do elemento no arquivo web.config do aplicativo for definida como true, o ASP.NET 2.0 compilará cada pasta no aplicativo em um assembly separado.
Isso pode acontecer se você colocar os arquivos .cs em App_Code e alterar sua ação de construção para compilar em um projeto de aplicativo da web.
Tenha a ação de construção para os arquivos .cs em App_Code como Conteúdo ou altere o nome de App_Code para outro nome. Mudei o nome, pois o intellisense não corrige os arquivos .cs marcados como conteúdo.
Mais informações em http://vishaljoshi.blogspot.se/2009/07/appcode-folder-doesnt-work-with-web.html
Uma possível razão para este erro é que existem 2 páginas aspx que estão tendo o mesmo nome em sua inherits=na<@page language=......inherits=> linha.
Alterar o inherits=nome resolve o erro.
Apenas no caso de outra pessoa compartilhar meu problema, recebi este erro ao tentar publicar um Web Site de um projeto recém-ramificado, build funcionou perfeitamente.
Acontece que eu tinha esquecido de remover a caixa de seleção "Permitir que o site pré-compilado seja atualizável" em Configurações de publicação -> Configurar pré-compilação .
Como outro ponto de dados, eu simplesmente tive esse problema sem nenhuma evidência de referências circulares, conforme descrito nos links na resposta de Ben. A construção do meu projeto de site da Web falhará com alguns desses erros e a configuraçãocompilation batch="false" corrigiu isso, mas eu não queria ir por esse caminho porque este é um site de produção grande.
Essa solução estava em uma subpasta da minha pasta D: \ svn, que mapeei para S :. Quando abri a solução do S :, esses erros ocorreram, mas se eu fosse direto para D: \ svn e abrisse a solução, sem erros.
Também notei que, apesar de ter compilation batch="true"no meu web.config, ao abrir a solução do S: drive mapeado todos os meus arquivos .ascx são compilados em seus próprios assemblies. Se eu abri-lo de um local físico, os arquivos .ascx são compilados nos assemblies de suas respectivas pastas (que é como batch="true"deveria funcionar).
Estranho.
Este erro foi devido ao conflito entre o nome da classe do formulário da web e wsdl stub (código por trás do arquivo .cs) com o mesmo nome de classe, ou seja
Página ASPX: Dashboard Class: partiacl class Dashboard
AppCode / APIServices.cs: painel de classe pública parcial
O erro foi reproduzível apenas na publicação do site, mas build e debug não informavam nenhum erro.
No meu caso, eu havia renomeado um projeto, então também a dll foi renomeada. Quando acabei de copiar a nova dll, mas não pensei em excluir a antiga do servidor, logo tinha um monte de pares de classes com os mesmos nomes. Excluir as dll desatualizadas estava resolvendo o problema (de causa).
Nenhuma dessas respostas funcionou para mim, no entanto, resolvi o problema. Como estava usando a função Publicar do VS para implantar o aplicativo da web, selecionei a opção de excluir todos os arquivos existentes antes de publicar no assistente Publicar Web. Isso forçou uma cópia limpa do aplicativo e tudo funcionou bem a partir daí.
Esta solução pode ser útil se sua cópia de depuração local funcionar bem, mas o sistema publicado não. Também é ótimo se você não quiser perder tempo rastreando dlls individuais para excluir e não se importa que os arquivos de produção sejam excluídos primeiro.
No meu caso, o problema foi resolvido quando editei um arquivo Designer.cs que ainda tinha o nome de classe duplicado. por alguma razão, quando eu renomei a classe "logout" para "logout2", no arquivo do designer ela não foi alterada automaticamente e ainda estava "logout", e esse nome de classe já existia em uma dll pré-compilada em meu projeto (que pertence para um aplicativo da web de terceiros com o qual trabalho e desenvolvo).
Tenho este problema ao colocar uma parte de uma página aspx no controle de usuário separado. Na minha maquina estava tudo bem, no servidor deu um erro.
Renomeou a classe e o arquivo do problema.
http://support.microsoft.com/kb/919284 Método 2: Reordenar as pastas no aplicativo está escrevendo sobre possíveis referências circulares
Nenhuma dessas soluções funcionou para mim. Ambas as minhas DLLs conflitantes estavam em C: \ ... \ AppData \ ... \ Temporary ASP.NET Files \ ...
O problema era que eu tinha revertido meu repositório de origem para uma versão anterior - antes de movermos um tipo de um projeto para outro dentro da mesma solução.
Tentei excluir a DLL mais recente - que nem deveria estar lá na base de código mais antiga - do local "Arquivos ASP.NET temporários" identificado por msbuild. msbuild basta colocá-lo de volta.
Eu também tentei a configuração web.config que alguns aqui usaram com sucesso, mas também não funcionou. Embora, enquanto escrevo isso, eu perceba que havia na verdade dois projetos MVC dentro da mesma solução e ambos tinham erros, então o problema pode ter sido que eu não adicionei a configuração a ambos.
Tentei rolar meu repositório de origem para frente e limpar e rolar novamente e limpar. Nada.
Tentei excluir tudo o local "Arquivos ASP.NET Temporários". msbuild basta colocá-lo de volta.
Por fim, tentei reconstruir no Visual Studio. Embora a saída da linha de comando e a saída "Erros" forneçam o mesmo erro msbuild "Arquivos ASP.NET temporários", o erro Intellisense - ao pairar sobre o tipo em conflito - na verdade reclamava sobre DLLs nos diretórios de saída. Aparentemente, "Limpar" e "Reconstruir" não estavam funcionando. Excluí manualmente as DLLs nos diretórios de saída identificados pelo Intellisense e o problema foi resolvido.
tl; dr - Certifique-se de estar cobrindo todos os seus web.configs com a configuração de lote e tente aproveitar o Intellisense para obter mais pistas.
Meu problema estava vinculado a um .dll que estava sendo gerado na pasta do meu projeto.
Se você estiver fazendo referência a outro arquivo, em vez de fazer tudo o que vê acima, o que corrigiu meu problema instantaneamente foi apenas excluir o .dll que estava dentro do diretório / bin do meu projeto.
O problema não é necessariamente uma correção web.config - é uma referência circular que precisa ser resolvida. Percebi que limpei o arquivo .dll antigo no meu arquivo de projeto original, mas não no projeto que o fazia referência.
Eu não recomendo fazer a modificação em seu arquivo web.config porque isso é apenas uma correção band-aid - não abordando realmente o problema real. Faça isso se não quiser resolver o problema, mas se quiser evitar dores de cabeça no futuro, basta remover o .dll de ambos os locais.
Às vezes, pode ajudar remover a solução e criá-la novamente. Como esse uso acontece quando convertido de VS2005 para vs2010, algumas referências ao framework 4.0 (após a atualização) permanecem na solução, mesmo todos os projetos são definidos como 3.5.
Normalmente, reconstruir a solução deve eliminar esses problemas.
Eu tive o mesmo problema quando estava compilando o aplicativo em um servidor de compilação.
Meu controlador tinha um código estático simples, então mudei meu ascx:
<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="controllerName.ascx.cs" Inherits="Controls.controllerName" %>Para
<%@ Control Language="C#" AutoEventWireup="true" Src="controllerName.ascx.cs" Inherits="Controls.controllerName" %>Também removeu a palavra-chave parcial do codebehind e adicionou um namespace ao codebehind.
Este:
using System;
using System.Web.UI;
/// <summary>
/// My controller
/// </summary>
public partial class controllerName: UserControl
{
protected void Page_Load(object sender, EventArgs e)
{
}
}Para isso:
using System;
using System.Web.UI;
namespace Controles
{
/// <summary>
/// My controller
/// </summary>
public class controllerName : UserControl
{
protected void Page_Load(object sender, EventArgs e)
{
}
}
}E isso funcionou para mim.
Para mim, isso aconteceu quando eu tinha meu local Pré-compilado da Web / Publicação definido como o diretório atual, onde estava a pasta raiz do site.
Meu Web Site estava vendo a pasta de publicação como parte do projeto ao compilar / construir e encontrar duplicatas dessa maneira.
ou seja, não coloque a versão publicada / pré-compilada do seu site nas pastas de código do seu site.
Se as DLLs estiverem aparecendo em uma pasta temporária, você deve tentar limpar sua solução.
Postando minha solução:
O problema estava relacionado à "Varredura ao acessar" do Mcafee Antivirus. Desativar isso resolveu o problema. De alguma forma, a pasta ASP Temporary não estava sendo usada corretamente pelo ASP quando o antivírus estava ligado.
Espero que isso ajude alguém.
A pasta App_Code está causando o problema, coloque a classe fora da pasta (funciona bem)
A pasta App_Code não foi projetada para projetos de aplicativos da Web
http://vishaljoshi.blogspot.in/2009/07/appcode-folder-doesnt-work-with-web.html
Eu enfrentei o problema em tempo de compilação.
Eu concordo com os atributos batch = "true" , o erro está dizendo que existem 2 montagens
Solução 1: excluir um deles
Solução 2: Configure um deles