/ / Localizando um formulário no namespace aninhado de repente gera exceções de tempo de execução - .net, visual-c ++

A localização de um formulário no namespace aninhado gera, de repente, exceções de tempo de execução - .net, visual-c ++

Tinha um formulário funcionando bem até localizá-lo - então ele gerou exceção de tempo de execução e recursos não foram encontrados.

O namespace é aninhado em um nível extra da raiz.

namespace MyApp
{
namespace NextLevel
{

<MyForm class>

}
}

e MyApp também correspondem ao nome do Assembly.

Removendo o NextLevel, portanto, apenas MyApp :: MyForm e funciona como antes.

Removendo localização e funciona também, como aninhado ou não.

Se de alguma importância, isso é C ++ / CLI e um assembly dll.

Eu tentei para os arquivos resx - adicionar o .NextLevel no meio para o modelo de nome de recursos, mas o resultado é o mesmo.

Meus recursos principais são neutros (incorporados) e depois ingleses (que se tornam satélites).

Alguma ideia?

Como os recursos são nomeados internamente para o gerenciador de recursos encontrá-los?

Muito grato.

Obrigado.

Respostas:

0 para resposta № 1

Resolvido - aqui está o que eu fiz.

Em um projeto paralelo eu tenho exatamente o mesmo problema / resultado adicionando um nível de espaço de nomes aninhados. Eu adicionei o nível extra como ".NesxtLevel" nos arquivos resx para criar nomes de recursos corretamente.

Eu adicionei o arquivo de recursos renomeados na entrada do vinculador como recurso gerenciado incorporado.

E isso funcionou - mas eu senti - por que deveria ter que inserir cada arquivo de recursos aqui manualmente.

Eu olhei para build log e vi that / out ainda referencia como / ASSEMBLYRESOURCE: o arquivo de recursos é o mesmo que basename para o arquivo resx mais rootnamespace, não o nome lógico com namespace extra nele.

Eu removi manualmente os arquivos de recursos antigos com o mesmo nome de base do arquivo resx.

E isso resolveu. Eu poderia remover o recurso incorporado que adicionei também nas opções do vinculador.

Sempre imaginei que a reconstrução do projeto tambémremoveu arquivos de recursos antigos, mas obviamente não. Portanto, parece que quando o VS está criando a linha de comando, se um arquivo de recursos existir com roonamespace + resx-filename como nome lógico - ele seleciona aquele - não aquele criado pelas configurações do compilador de recursos.

É VS 2005, então não adianta falar com MS sobre isso. Apenas feliz que isso esteja resolvido.