Equivalent of Tuple (.Net 4) for .Net Framework 3.5

Equivalent of Tuple (.NET 4) for .NET Framework 3.5

No, not in .Net 3.5. But it shouldn't be that hard to create your own.

public class Tuple<T1, T2>
{
    public T1 First { get; private set; }
    public T2 Second { get; private set; }
    internal Tuple(T1 first, T2 second)
    {
        First = first;
        Second = second;
    }
}

public static class Tuple
{
    public static Tuple<T1, T2> New<T1, T2>(T1 first, T2 second)
    {
        var tuple = new Tuple<T1, T2>(first, second);
        return tuple;
    }
}

UPDATE: Moved the static stuff to a static class to allow for type inference. With the update you can write stuff like var tuple = Tuple.New(5, "hello"); and it will fix the types for you implicitly.

Is there something like tuple in .net 3.5

No, there isn't anything in .NET 3.5. But rather than Tuple, have you considered implementing your own simple type which encapsulates the members you need? Usually that ends up giving more readable code than Tuple anyway - especially when you've got quite a lot of members, most of which have the same types.

It's a lot easier to understand:

foo(sale.AdultTickets, sale.ChildTickets, ...);

than

foo(sale.Item1, sale.Item2, ...);

It's a little bit more work, but it needn't be much more.

What's a good object to store 3 data types a la list/tuple in .NET 3.5

Have a look at this open source Tuples implementation for .net 3.5

.NET framework 3.5 vs. prior versions?

The redistributable does not.

.NET 3.5 supports all of the .NET 1.0, 1.1, 1.2, 2.0, 3.0 codebase (although some things may be changed up a bit, marked obsolete, etc...).

But if you install .NET 3.5 you will need to install .NET 1.1 to run an app compiled against that CLR.

However, .NET 2.0, 3.0, 3.5 all share the same CLR so you may be able to run .NET 2.0 apps w/ the 3.5 redist, I'd have to test it to be sure.

Compatibility Pack for backporting new .NET Framework features?

Theraot's Libraries

You can use use Theraot.Core from Theraot's Libraries to backport a great portion of .NET code to old versions starting with .NET 2.0 thanks to conditional compilation.

Out of the mentioned features, the following are included:

• ExtensionAttribute
• Func<...> and Action<...> delegates
• LINQ-to-objects
• Tuple<...>
• Lazy<T> and Lazy<T,TMetadata>
• Expression Tress

Also included are the following features not mentioned in the question:

• HashSet<T>
• SortedSet<T>
• ThreadLocal<T>
• IObservable<T> and IObserver<T>
• BigInteger
• ConcurrentDictionary<Tkey, TValue>
• etc...

Note: Support for System.Threading.Tasks is planned.

Sadly, there is only little documentation available at the moment of writing, yet any difference on behavior from the BCL can be considered a bug, and can be reported via github.

Which methods in the 3.5 framework have a String.Format-like signature?

There are a lot of methods that support this throughout the framework. All subclasses of TextWriter (and therefore StreamWriter and StringWriter and their subclasses) will inherit the Write method that supports this.

Another example that is often used is StringBuilder.AppendFormat.

You can write your own methods to support this too. You can do it by having an overload with a format string parameter and another parameter with the params keyword, like this:

public void Foo(string message) {
    // whatever
}

public void Foo(string format, params string[] arg) {
    Foo(string.Format(format, arg));
}

Will a future version of .NET support tuples in C#?

I've just read this article from the MSDN Magazine: Building Tuple

Here are excerpts:

The upcoming 4.0 release of Microsoft
.NET Framework introduces a new type
called System.Tuple. System.Tuple is a
fixed-size collection of
heterogeneously typed data.
 
 

 

Like an array, a tuple has a fixed
size that can't be changed once it has
been created. Unlike an array, each
element in a tuple may be a different
type, and a tuple is able to guarantee
strong typing for each element.

 

There is already one example of a
tuple floating around the Microsoft
.NET Framework, in the
System.Collections.Generic namespace:
KeyValuePair. While KeyValuePair can be thought of as the same
as Tuple, since they are both
types that hold two things,
KeyValuePair feels different from
Tuple because it evokes a relationship
between the two values it stores (and
with good reason, as it supports the
Dictionary class).

Furthermore, tuples can be arbitrarily
sized, whereas KeyValuePair holds only
two things: a key and a value.

---

While some languages like F# have special syntax for tuples, you can use the new common tuple type from any language. Revisiting the first example, we can see that while useful, tuples can be overly verbose in languages without syntax for a tuple:

class Program {
    static void Main(string[] args) {
        Tuple<string, int> t = new Tuple<string, int>("Hello", 4);
        PrintStringAndInt(t.Item1, t.Item2);
    }
    static void PrintStringAndInt(string s, int i) {
        Console.WriteLine("{0} {1}", s, i);
    }
}

Using the var keyword from C# 3.0, we can remove the type signature on the tuple variable, which allows for somewhat more readable code.

var t = new Tuple<string, int>("Hello", 4);

We've also added some factory methods to a static Tuple class which makes it easier to build tuples in a language that supports type inference, like C#.

var t = Tuple.Create("Hello", 4);

Dictionary with own tuple

You need to specify the generic parameters of your Tupla class.

public class ParametrosMultiples : Dictionary<String, Tupla<type1,type2>>
{

}

Though the error you are getting seems to suggest that this class is either in a separate assembly that has not been referenced, or (if it is referenced or is in the same assembly), that you have not imported the namespace it lives in into the class that needs to use it with a using directive.

You also seem to have two separate classes (a static and a "normal" one) with the same name - Tupla. This will certainly cause a naming conflict. Consider changing the name of one of them, or incorporate the functionality into a single class.

---

Related Topics