A question about classes / enumerated types/ best practice etc..

[BradNeedsYourHelp]

I have a quick query about classes, and standards.
This is probably a very easy/stupid question or I am over complicating a simple process. In any case, please advise..

If you have an instance of a class, which has an attribute (e.g Value) where the values can only be taken from a set list e.g {0,1,2,3,4,5,6,7}.

When writing code, when using this attribute one might type:

myClass.Value = 2

But if I wanted to make the line more abstract by saying

myClass.value = Tuesday

I could use an enumerated type outside of the class, where Tuesday would represent 2, Wednesday 3 etc.. to get this abstraction. However, is it better to create a class type library!?!?! e.g have something like (where myWeek is an instance of the class type)

myClass.Value = myWeek.Tuesday

I am getting confused, I am using VB6/VBA and whilst I could create a type library dll , I don't want this code to rely on external dll.

Is this how VB.NET works!?

Just trying to code professionally.

thanks for any advice.

[TheMonkey]

Just make an enumeration in a shared assembly public (Create a file WeekDaysEnum.vb) and reference it if you need to from other projects. You don't need to instantiate an enumeration so:

' Enumeration
Public Enum WeekDays
   Monday, Tuesday, Wednesday ....
End Enum

' Reference with

WeekDays day = WeekDays.Tuesday

Console.WriteLine(day.ToString())

If it's shared, you will need to stick it in another DLL (class library project). It's not uncommon in .Net applications to throw several DLLs in the application root. Just add a reference to that DLL in anything that needs to use it.

Apologies for any crappy code - my VB.Net is terrible as I'm a C# guy.

[AtW]

Its best to always instantiate enumerations and when you add new don't break the numbering (if you have to use numbers with 10 or 20 increments, this will allow to insert new one between without changing others) - add at the end of it with new numbers.

[ASB]

This may well not be the case with enums (I doubt it is) but be careful with public constants in other assemblys. They are copied into a referencing assembly at compile time, thus if the constant is changed and the client assembly is not recompiled then you are stuffed. Expose them as properties instead and use that. Of course this behaviour may have changed since I fell over it but I cant be bothered to check.

[AtW]

I am pretty sure almost all assemblies are copied into apps directory by VS, so if you change some dependency you need to recompile everything that depends on it.

[ASB]

I am pretty sure almost all assemblies are copied into apps directory by VS, so if you change some dependency you need to recompile everything that depends on it.

Agreed, but the problem relates more to deployment of a later patch. This exemplefies the issue rather better than I did.

http://haacked.com/archive/2005/01/02/1796.aspx

[AtW]

But surely deployment of a patch would include deployment of all changed DLLs, which for practical purposes means all of them? I generally avoid referencing DLLs (unless they never change, and by that I mean never) directly, I prefer to create solution with all relevant projects in the same solution, so that build of it would ensure everything is up to date.

[ASB]

Yes but the (dubious) point is that the normal expectation is that a client DLL is dependant upon that dll at run time - not at compile time. It's not an entirely unreasonable assumption that shipping the changed dll should satisfy the clients requirements for it referred methods/properties/constants. It only satisfies the first two. Thus it is an inconsistancy.

[AtW]

Would not strong naming take care of this situation, which is effectively multiple versions of same named DLL?

[ASB]

Would not strong naming take care of this situation, which is effectively multiple versions of same named DLL?

Yes, but then that stuffs the deployment model of just issuing a patch to the erroneous DLL.

But this started as a note to the OP of a reason why public constants may be a bad idea in some cases - which was the entire point. i.e. Do this and this will happen. It might be unhelpful.