Compatibility of DLLs across .Net


My company is intending to develop a suite of DLLs, based on Class Libraries, containing all sorts of standard functions, subroutines and controls that we use in our own developed applications. The DLLs will be developed solely for use on .Net and we will use VB.Net to develop them.

The beauty of using .Net is that, according to the manuals, other developers can invoke these DLLs from any programming language in Visual Studio .Net, for instance C#. However, we have had no experience of this. My questions are therefore:

1.      Is this true? Can other .Net languages use our DLLs unchanged?

2.      If not, are there measures we can take in the DLLs to increase the compatibility with .Net Programming Languages other than VB.Net?

3.      What about use of our .Net DLLs from Internet applications?

4.      Can anybody recommend reading matter that would be relevant?

I’d appreciate some advice on this matter.

Thanks in advance.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Fernando SotoRetiredCommented:
To your question, " Is this true? Can other .Net languages use our DLLs unchanged?", Yes, this is possible because .Net applications compile into what is called Intermediate Language, IL, which all .Net language compile into which is the same across all the languages. The only thing you need to make sure is that the DLL is developed in the same platform. For example if you develop the DLL for a 64 bit machine then the developer must develop with 64 bit and not 32 bit. Developing using 32 bit will work on both 32 and 64 bit machines.

To your question, "What about use of our .Net DLLs from Internet applications?", this should not be a problem because the DLL are run on a Windows machine.

The only other thing I can think of is to make sure that you use compatible .Net versions. For example if you develop with .Net 5.0 and using functions that were newly implemented in 5.0 then you will need to load .Net 5.0 on the machine that do not have 5.0 on them.
Jacques Bourgeois (James Burger)PresidentCommented:
To put all of that in perspective, .NET is completely independent of the language, as long as you use the .NET version of the language.

Modern languages do not do much by themselves. Internally, they declare variables, constants and methods, run decisions and loops, but that is all. Under the hood, they do nothing, except to call a runtime (dll) that provides the functions they need.

Contrary to older environments, where each language had its own runtime and its own conventions (such as True=-1 in VB and true=1 in C), all the .NET language compile to a standard runtime, the Common Language Runtime (CLR).

These languages thus all have the same conventions and use the same methods. Although the syntax for dealing with dates might be different for instance, all languages use the same methods, with the same arguments, and the internal representation of the date is exactly the same. All you do with the language is manipulate the .NET framework. Same thing for the strings. Same thing for everything. COBOL.NET uses the same methods, with the same conventions, as C# does.

Once compiled a .NET dll is a .NET dll. It's neither a C#, a VB, a Fortran nor a COBOL dll.

As far as calling a dll goes, it makes no difference whether you are developing a service, a Windows application, a Phone application, a Web application or a tablet application. There are differences on the design and creation of the user interface, but these things are relatively not important unless you create a dll that is specifically geared toward helping with a given type of interface. In such a case, you might need multiple versions of your dll.

But if all your dll does is provide classes and methods to manipulate data, then there is not much to be wary of. The only limitations might come if you think of installing the dll on something else than a server or a desktop, say on a tablet or phone. The version of the framework that is provided in smaller machines does not offers all the classes of the standard version because of size considerations. So a dll conceived for a desktop will probably not run on a mobile. That is one of the reasons that you hear a lot about services and cloud these days. These enable you to install the dll on a server and call it from anywhere and with anything, big or small.

And Fernando was also right pointing out that you need to decide on which version of the framework you will be targeting. If its for internal use, just decide on one (usually the most recent) and target that version of the framework in all you applications and dlls.

But if you think of creating dlls that will also be used outside of your organization, you might prefer to target an older version of the framework. A computer that has framework 4.5.2 installed can easily run stuff built for framework 4.0. But the reverse is not true. If you do not have control over your customers environment, then you need to work in such a way that the application will be able to run on older installations.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
PirieAuthor Commented:
The 2 comments increased my confidence that what the text books claim is really true, although I would have liked explicit mention that it worked for the Experts in practice i.e. they actually used DLLs created with VB.Net using C# with no problems at all.

The tip about being careful of which version of .Net framework to use was a useful reminder. I have had personal experience of using VB.Net to create an application for a Pocket PC, in which many controls were not available. It's a bind to have to, for instance, create the equivalent of a Combo box by manually superimposing a list box onto a text box. However, this won't happen in this case since we're dealing with Desktops and Laptops all round.

Thanks again, Experts.
Jacques Bourgeois (James Burger)PresidentCommented:
You can assume that you had an explicit mention that it works. Most experts here talk from experience, not from stuff they have read here and there.

I have a VB.NET dll that I use extensively in all my applications. It contains common constants and routines such as my email address, the logo of my company, methods to calculate taxes and log exceptions. I use that dll with all my applications, without exceptions. Although I program mostly in VB, I also have a couple of applications that were written in C# because that is what my customer wanted. My dll works flawlessly with all these C# applications.

I also distribute a generic version of that dll with my training material for the ADO.NET course that I give since 2002. Half of the programmers who trained with me are C# programmers, and many of them use that without any problem. Only once in all these years did I have to make a minor adjustment to one of the methods in order to make it work with C#.
PirieAuthor Commented:
Thanks Jacques for all your help. I'll now proceed with 100% confidence.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual C++.NET

From novice to tech pro — start learning today.