0

I am working on a commercial .NET developer library that I hope to go public with and I want to know what versions of the .DLL I should provide out of the box to the end user (developers).

The .DLL might be executed in a wide variety of enviroments that I can't predict.

My current plan is to provide:

  • Both .NET3.5 and .NET4 compiled version
  • Each version signed any unsigned
  • One compiled 32-bit and one compiled 64-bit

Totally 8 different editions.

The question is if this is a good strategy?

Should I perhaps also make a "AnyCPU" compiled version for those who prefers that that runs the DLL in both 32 and 64 bit environments?

I don't care about the extra work doing all these editions as I easilly can do that in my automated build/packaging.

Tore Nestenius
  • 16,431
  • 5
  • 30
  • 40
  • 1
    I would skip the 32/64 bit builds and just ship an Any CPU build, if the assembly doesn't care about what platform it runs on. Any CPU means the assembly is not specific to the 32-bit or 64-bit runtime, and can be used by either one. What's the point in providing an unsigned / signed version? Why not just "signed"? Realistically I don't see why you can't just ship 2; one for CLR v2 and for CLR v4. – vcsjones Jan 06 '12 at 17:14
  • Does your application really benefit from compilation? – Igor Korkhov Jan 06 '12 at 17:15
  • Why different version is that if a developer developing a 64 bit signed application, then I assume he wants the DLL to be a signed 64 bit DLL. Its's a DLL that is somewhat perf critical. – Tore Nestenius Jan 06 '12 at 17:17
  • If you have a signed version, is there any reason to include an unsigned one? (I'm not sure, hence the question). I'd think that a 3.5 and 4.0 signed version each, any cpu, should be good. And make the 3.5 version a 2.0 or 3.0 if possible. (not extra versions... just the lowest one required by the code, which may *be* 3.5) – Andrew Barber Jan 06 '12 at 17:17
  • @Andy Any CPU vs. a specific DLL for 32/64 will not make any difference in performance. – vcsjones Jan 06 '12 at 17:20

1 Answers1

1

There is no reason to build your libraries as 32 bit or 64 bit because 'bitness' of a process is decided on application start up depending on .exe file and OS. It doesn't matter which you choose. If your library does however have some executable file, there may be a reason to have 32 bit build. This is the case only if your application depends on 3rd party 32 bit library (uses COM interop).

As for signed/unsigned dilemma, I don't see why you should ship both. If you want to place a restraint on developer, use signed, otherwise just leave it unsigned.

Nikola Radosavljević
  • 6,871
  • 32
  • 44