Pergunta

Lembro-me de volta ao trabalhar com MFC você poderia suportar várias versões do framework MFC, verificando a macro _MFC_VER.

Eu estou fazendo algumas coisas agora com .NET 4 e gostaria de usar Tuple em um par de pontos, mas ainda manter tudo o mais 3,5 compatível.

Eu estou olhando para fazer algo como:

#if DOTNET4
    public Tuple<TSource, TResult> SomeMethod<TSource, TResult>(){...}
#else
    public KeyValuePair<TSource, TResult> SomeMethod<TSource, TResult>(){...}
#endif
Foi útil?

Solução

Não há constantes builtin pré-compilador que você pode usar. Mas, é bastante fácil criar suas próprias configurações de compilação em VS com cada configuração que tem seu próprio conjunto de constantes definidas e, claro, uma versão do framework de destino. Um monte de gente fazer isso para 32 ou 64 bits diferenças condicionalmente compilar base.

Outras dicas

Há uma grande limitação para estar ciente de quando definir símbolos de compilação personalizada em seu .csproj (ou .vbproj, teoricamente): que substituir todos os símbolos de compilação anteriormente definidas. Por exemplo, considere MSBuild trecho:

  <PropertyGroup Condition="'$(TargetFrameworkVersion)' == 'v4.0'">
    <DefineConstants>$(DefineConstants);DOTNET_40</DefineConstants>
  </PropertyGroup>
  <PropertyGroup>
    <DefineConstants>ITS_CLOBBERING_TIME</DefineConstants>
  </PropertyGroup>

O segundo elemento DefineConstants irá, como o seu valor sugere, clobber o primeiro valor de DefineConstants. Para evitar isso, você vai querer reescrever o segundo elemento DefineConstants para ficar assim:

    <DefineConstants>$(DefineConstants);ITS_CLOBBERING_TIME</DefineConstants>

Além disso, você vai querer colocar isso dentro de um PropertyGroup definidos após todas as outras PropertyGroups, como Visual Studio 2010 adiciona atualmente em símbolos de compilação personalizados, de tal forma que ele vai espancar qualquer outro costume símbolos de compilação você define se eles são colocados antes estatela Visual Studio para baixo sua definição. Eu apresentado esta questão com a Microsoft. Você pode acompanhar seu progresso em Microsoft Connect .

Em uma nota lateral, o seu código de compilação condicional irá frustrar os programadores que encontrá-lo.

editadas, com base nos comentários

É provavelmente melhor para escrever sua própria classe para que você pode garantir o que vai fazer, e você não tem quaisquer problemas de assinatura ou de herança estranhas:

public class Pair<TSource, TResult>
{
    public TSource Source { get; set; }
    public TResult Result { get; set; }

    public Pair() {}
    public Pair(TSource source, TResult result)
    {
        Source = source;
        Result = result;
    }

    // Perhaps override Equals() and GetHashCode() as well
}

Como sempre, é bom para pesar usando o built-in coisas vs. lançando seu próprio código. Geralmente isso significa perguntando, "Am I OK manutenção e suporte esse código?" versus "O código de fazer o que eu preciso que ele, fora da caixa?"

Neste caso, uma vez que você não está garantido para ter Tuple<T1, T2>, eu tinha acabado de escrever seu próprio simples para que outros desenvolvedores podem respirar fácil:)

Como você deve ter projetos diferentes, você poderia ter classes parciais e apenas referenciar o que você precisa para cada projeto com a lógica específica para eles:

classname.cs classname parcial público {...}

classname.40.cs classname parcial público { pública Tuple SomeMethod () {...} }

classname.35.cs classname parcial público { pública KeyValuePair SomeMethod () {...} }

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