Estabilidade do .NET serialização em diferentes versões quadro

Question

Um projeto que estou trabalhando em requer a serialização de uma estrutura de dados antes de desligar e restaura seu estado a partir destes dados serializados quando ele começar de novo.

No ano passado, estávamos construindo para .NET 1.1, e correu para uma questão complicada, onde

• nossa correu código em .NET 2.0
• um cliente atualizado com algum software que de alguma forma definir 1.1 como padrão
• nossa correu código em .NET 1.1 e foi incapaz de desserializar seu estado armazenados

Esta questão em particular foi "resolvido", impedindo que a atualização de software em particular, e não deve ser um problema agora que estamos visando o framework .NET 2.0 (por isso não podemos possivelmente executado em 1.1).

Qual é a chance de que isso serialização poderia voltar a mudar incompatibly entre, 2.0 e os quadros mais recentes? Se usarmos <supportedVersion> para corrigir o nosso código para 2.0.50727, quais são as chances de mudanças entre 2.0.50727.1434 e 2.0.50727.nnnn (alguns versão futura)? As estruturas de dados sendo serializados são matrizes, mapas, cordas, etc. a partir de bibliotecas de classe standard.

Além disso, é garantido que um quadro 2.0.50727 será sempre instalado mesmo depois de mais atualizações .NET? Ponteiros para Microsoft documentação de boas-vindas.

Answer 1

As chances são baixas (mas não é zero!) Que não haverá mudanças entre as versões do framework. A intenção seria que você deve ser capaz de usar binário serialização e comunicação remota para a comunicação entre um cliente e um servidor rodando diferentes versões do framework. A incompatibilidade entre .NET 1.x e 2,0 é um erro para as quais está disponível um patch.

No entanto serialização binária tem outros problemas, especialmente pobre suporte para controle de versão da estrutura que está a serialização. A partir do caso de uso que você descreveu, XML serialização é a escolha óbvia: DataContractSerializer ser mais flexível do que o XmlSerializer se você não se importa a dependência de .NET 3.x

.

Você não pode garantir que o .NET framework 2.0 irá sempre ser instalado em versões futuras do Windows. Mas eu tenho certeza que a Microsoft vai trabalhar duro para garantir que a maioria .NET 2.0 aplicativos será executado inalterado em .NET versões posteriores 4.xe. Eu não tenho quaisquer referências para isso:. Tal compromisso seria, em qualquer caso, apenas se aplica realmente a próxima versão do Windows (Windows 7)

Answer 2

A regra de ouro é geralmente:. Serialização XML deve ser capaz de sobreviver novas versões estruturais e, portanto, pode ser armazenado a longo prazo, mas serialização binária não pode (e, portanto, só deve ser transitória)

Answer 3

O que serializer você está usando? De muitas maneiras, um serializador como XmlSerializer ou DataContractSerializer buffers-lo de muitos detalhes, e oferece opções de extensibilidade mais simples. Em algum momento, uma nova versão CLR será sem dúvida necessário - então eu não acho que ninguém pode fazer quaisquer garantias sobre 2.0.50727; você deve ser seguro de curto prazo, no entanto. E eu espero por mudanças menos quebrando ...

[atualizado seguinte nota em outra resposta]

Se você quiser um formato binário por razões de espaço / desempenho, em seguida, outra opção é usar um serializador binário diferente. Por exemplo, obras protobuf-net em todo o .NET variantes *, mas o binário format (dvised pelo Google) é compatível com várias plataformas (Java, C ++, etc.) - o que torna muito portátil, rápido e pequeno

* = Eu não tentei em micro quadro, mas CF, Silverlight, Mono, .NET 2.0 etc são todos suportados.

Answer 4

Se a compatibilidade é uma preocupação, a ISerializable de interface pode ser a cura que você está procurando. Esta interface dá-lhe mais controle sobre como os itens são serializados. Para mais informações tentar este href="http://msdn.microsoft.com/en-us/library/ty01x675.aspx" artigo no MSDN .

Answer 5

Eu tenho duas coisas a acrescentar às outras respostas ...

Em primeiro lugar, fazendo uso de um costume SerializationBinder você pode obter lotes redondos de dificuldades para importar dados legados serializado.

Em segundo lugar, considero que é obrigatória para escrever extensos testes unidade para qualquer dados persistentes. Eu sempre fazer dois testes em particular:

1. teste de ida e volta - você pode serializar e desserializar seus objetos e obter exatamente a mesma coisa para trás
2. Legado teste de importação - Verifique se você tem as versões de dados serializados exportados de cada versão lançada de seu aplicativo. Importe os dados e verificar que tudo vem novamente como esperado.

Answer 6

Você não tem que usar XML a fim de obter maior flexibilidade e controle de versão.

Eu tenho usado biblioteca de código aberto de Simon Hewitt, veja Otimização de serialização no .NET - parte 2 em vez de padrão .NET serialização. Ele oferece algumas automação, mas, essencialmente, você pode controlar o fluxo de informação que é serializado e deserialised. Controle de versão a versão (arquivo) pode ser serializado em primeiro lugar e em tempo deserialisation a forma como o fluxo de informação é interpretada depende da versão.

É muito simples de fazer, embora um tanto tedioso devido à explícita serialização / deserialisation.

Como um bônus que é 20-40 vezes mais rápido e ocupa menos espaço para grandes conjuntos de dados (mas pode ser importante no seu caso).