Solved

.Net dll name and version conventions

Posted on 2011-03-25
7
639 Views
Last Modified: 2013-11-08

I have a .Net component, which is a DLL file, that support .Net 1.1, 2.0, 3.0, 3.5 and 4.0.

Right now all DLL has the same name, and I differentiate the .Net version in the DLL version.
So, my dll for .Net 1.1 version is: MyComponent.DLL and if you look inside it's version is 9.0.1.1
The dll for .Net 2.0 is the same MyComponent.DLL and if you look inside it's version is 9.0.2.0 and so on.
As you notices, I put the .Net version inside the product version.

But I don't like it. I was told to do so from my contractor, but I'm not sure this is the correct way, I don't feel it is.
I'd be more comfortable to name it  like MyComponent.v1.1.dll and then us the version number to put the MyComponent version number.

What do you think?

What's the correct convention in this case?

0
Comment
Question by:fischermx
7 Comments
 
LVL 35

Accepted Solution

by:
Miguel Oz earned 300 total points
ID: 35220750
Naming convention is always a ddificult topic:
I will go for names rather versions numbers:
MyComponent.NET20.DLL
MyComponent.NET35.DLL
MyComponent.NET40.DLL
The version number is to identify the release itself. eg. this is version 9.3.0.0 and it is available for .net 2,3.5 and 4

Others use this convention. Check:
http://ajaxcontroltoolkit.codeplex.com/releases/view/43475
0
 
LVL 3

Assisted Solution

by:uanmi
uanmi earned 200 total points
ID: 35220762
The convention that you have been told to use is correct. It is normal to use the version number to differentiate between supported framework version.

The dll name can really be anything, but so there don't end up being many installed on a system it is normal to use the same name for dlls

check out
http://blogs.msdn.com/b/brada/archive/2003/04/19/49992.aspx
http://10rem.net/articles/net-naming-conventions-and-programming-standards---best-practices
http://www.beansoftware.com/NET-Tutorials/Net-Assemblies.aspx
regards, Mark
0
 
LVL 3

Expert Comment

by:uanmi
ID: 35220774
Oh, I should mention that the critical issue is that a DLL include correctly defined assemblies and be designed to provide backwards compatibility if necessary for systems that may have more than one application installed.

Often you see software install shared dlls (and inside there are the assemblies) into the Shared Tools folders so that backwards compatibility will occur and to ensure there is only one dll installed on a PC - the apps all try to install the dll to the one shared folder. This way you can test to see if the dll being installed is older than a current one and not install it. This relies on the new dll supporting old framework releases as well.

regards, Mark
0
3 Use Cases for Connected Systems

Our Dev teams are like yours. They’re continually cranking out code for new features/bugs fixes, testing, deploying, testing some more, responding to production monitoring events and more. It’s complex. So, we thought you’d like to see what’s working for us.

 
LVL 11

Expert Comment

by:SAMIR BHOGAYTA
ID: 35220813
0
 
LVL 3

Expert Comment

by:uanmi
ID: 35220816
wow samirbhogayta, I listed that article earlier - thank you for listing it again.

regards, Mark
0
 
LVL 35

Expert Comment

by:Miguel Oz
ID: 35225814
Other famous component using my posted convention:
http://www.obout.com/inc/download.aspx
It also depends:
1) How you build your component? As one solution (my prefered option) or multiple solutions.
2) How you install your component, what happen if you have a user that has Vs2005 and VS2008 installed and used both. or in my case I have to use vs2008 and vs2010, because M$ in is infinite wisdom only support VSTO for Excel 2007 and 2010 but not 2003, thus my need to build in vs2008.
e.g.: programfiles\mycomponent\.net2.0\your files here. thus the need to have your component available for multiple versions of .net.

Note: Most important is whatever you feel confortable and it is consistent usage in your organization.
0
 
LVL 1

Author Closing Comment

by:fischermx
ID: 35233561
Thank you!
0

Featured Post

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

A long time ago (May 2011), I have written an article showing you how to create a DLL using Visual Studio 2005 to be hosted in SQL Server 2005. That was valid at that time and it is still valid if you are still using these versions. You can still re…
It was really hard time for me to get the understanding of Delegates in C#. I went through many websites and articles but I found them very clumsy. After going through those sites, I noted down the points in a easy way so here I am sharing that unde…
I designed this idea while studying technology in the classroom.  This is a semester long project.  Students are asked to take photographs on a specific topic which they find meaningful, it can be a place or situation such as travel or homelessness.…
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …

911 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

22 Experts available now in Live!

Get 1:1 Help Now