Pergunta

Atualmente, estou trabalhando em um controle de servidor para outros aplicativos em nossa empresa para interface com um serviço WCF. Toda vez que faço uma mudança de código de alteração e recomponho o controle, incremento a classe AssemblyVison e AssemblyFileVersion na AsseemblyInfo.cs por um. Por exemplo, minha última compilação passou de 1.0.07.0 para 1.0.08.0.

Quando o aplicativo consumido atualiza o arquivo copiando o arquivo mais recente no diretório do bin e tenta compilar, eles recebem o seguinte erro:

O nome do tipo ou namespace 'MyControl' não existe no namespace 'mynamespace' (você está perdendo uma referência de montagem?)

Para resolver esse erro, eles precisam excluir a referência atual e aumentar a referência.

Existe alguma maneira de atualizar o controle do servidor sem precisar excluir e adquirir novamente a referência?

Não estou forte nomeando o controle do servidor.
@Jpunyon - Você quer dizer que o aplicativo consumidor adicione o projeto de controle do servidor à sua solução?

Foi útil?

Solução

Clique com o botão direito do mouse na referência de montagem no explorador de soluções, Propriedades, desative a opção "versão específica".

Outras dicas

No meu caso, foi um projeto definido usando a estrutura de destino: ".NET Framework 4.0 Perfil do cliente" que tentou fazer referência a projetos de DLL definidos usando a estrutura de destino: ".NET Framework 4.0".

Depois de alterar as configurações do projeto para usar a estrutura de destino: ".NET Framework 4.0" Tudo foi construído bem.

Clique com o botão direito do mouse no projeto

Você está nomeando suas montagens fortes? Nesse caso, não é uma boa ideia incrementar automaticamente seu número de construção, porque com cada novo número de construção, você também precisará atualizar todas as suas referências.

Eu bati na resposta que me apontou na direção certa, mas ...

Para aqueles que estão usando C ++ visual:

Se você precisar desativar o incremento automático da versão, poderá alterar esse valor no arquivo "AssemblyInfo.cpp" (todos os projetos CLR têm um). Dê um número de versão real sem o asterisco e ele funcionará da maneira que você deseja.

Só não se esqueça de implementar seu próprio controle de versão em sua montagem!

No meu caso, tive que alterar a configuração local de cópia para True (clique com o botão direito do mouse no Solution Explorer, selecione Propriedades, localize e altere o valor da cópia de propriedade local). Depois que essa configuração foi alterada, a publicação do meu serviço WCF copiou o arquivo para o servidor e o erro desapareceu.

Ao criar um novo projeto UWP em branco na comunidade do Visual Studio 2017, esse erro surgiu.

enter image description here

Após o remédio sugerido (Restaurando o Nuget Cache), a referência ressurgiu no projeto.

Encontrei esse erro com um pipeline de construção do Azure DevOps (MS-HOSTED) em um repo TFVC.

No meu caso, eu estava trabalhando em uma filial e acidentalmente adicionou a referência da pasta do pacote no porta -malas, em vez de da filial. Depois que adicionei a referência de dentro da filial, ela começou a compilar com sucesso.

Isto é, enquanto trabalhava em ramo-beta sierra.csproj, acidentalmente referenciei trunk packages delta.dll. Obviamente, eu precisava fazer referência a ramo-beta pacotes delta.dll. A mistura ocorreu porque o caminho não é exibido com destaque no Adicione referência Janela e eu não verifiquei com cuidado o suficiente.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top