|
If your DLL is built for 4.5, then you app needs at least 4.5 as well.
But if your DLL is built for 2.0, then your app needs at least 2.0, but can use 3.0, 4.0, or 4.5 without any problems.
Bartosz Jarmuż wrote: What's the harm of rebuilding the app that uses it?
Change control.
Rebuilding a production app means change control to track who has what, who changed what, and why.
If you have added functions to the DLL, the exe that references it doesn't have to change.
Bartosz Jarmuż wrote: As for the part about the consumer, you mean a scenario where I deliberately or accidentaly change the code of the helper files while working on a project that uses it? That would definately be a problem, but I suppose only in case if more than one person worked on it...
Even if there is only one person, it's too easy to change something in a hurry - and then you end up not knowing which code you want. And you have to check which app has what code when you fix a bug in the "dll" code to make sure that you fix it there as well.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
|
You're welcome!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Some other things you might want to throw into the mix.
Keep your helper code in its own project and for each client app have a solution that contains the helper project and the client app project, and the client project has a project reference to the helper project. That way your latest version of the helper is always compiled\included with the client app and you can make changes to both on the fly. When you next open a different client app solution it'll see all the changes you made to the helper. It's just an easier way of managing things so you don't have to worry about dll references.
Second you could maybe keep the helper assembly in the GAC so it is automatically found by client apps. That way updating the GAC on one machine means all your client apps see the helper. It also means you can distribute just the client exe and as long as the target machine has the helper in the GAC the client app will work. If you do this you'd need to be very careful that changes to the helper don't break other apps as they'll all be using it.
|
|
|
|
|
Quote: Keep your helper code in its own project and for each client app have a solution that contains the helper project and the client app project, and the client project has a project reference to the helper project. That way your latest version of the helper is always compiled\included with the client app and you can make changes to both on the fly. When you next open a different client app solution it'll see all the changes you made to the helper. It's just an easier way of managing things so you don't have to worry about dll references.
Hmm, actually that's one of the things I tried first - however, I got puzzled by the fact that I cannot do 'Add as link' in case of adding the project - so I thought I would lose the single central location of the project if doing so. However, I've checked now and it appears that if I add the project and edit it, the changes get updated throughout all the applications.
Thanks (actually, that's a third, different approach which makes me even more puzzled)
|
|
|
|
|
Actually if you add the reference to the entire project, then the project is not compiled into the app - it is still added as a separate .dll file.
|
|
|
|
|
Bartosz Jarmuż wrote: Actually if you add the reference to the entire project, then the project is not compiled into the app - it is still added as a separate .dll file.
I didn't say otherwise.
|
|
|
|
|
Over a decade of working with the .NET Framework, I've learned some hard lessons about developing and using helper classes. My rules of thumb for helper classes are simple and straightforward.
1) Target the lowest version of the framework that supports the method, defaulting to 2.0.
2) Segregate classes by target framework.
3) Keep helper assemblies out of the Global Assembly Cache.
I repeat: Stay away from the GAC. It's a sand trap. I've had no end of grief from putting assemblies into it.
First, everything that goes into the GAC must be signed with a strong name, which means that you must keep up with the key file and its passphrase.
Second, it adds a step to the installation, which requires you to either know the whereabouts of GACUTIL.exe on their machine, or ship a copy with your package.
Third, the GAC on the user's machine becomes cluttered with old versions of your assembly, which may have become obsolete. So, you have created for yourself another maintenance issue.
OTOH, if you put the helpers into one or more assemblies, each in its own project, then set a reference that points to the Release build of the assembly (in the /bin/Release directory of the project), it gets copied automatically into the /bin/release directory of your current project. If you change the satellite assembly, the next build of any project that has a reference to it gets a fresh copy. When you are ready to ship, everything you need to ship should be in the /bin/Release directory, which was the point behind the much-touted XCOPY install.
With respect to the routines that require the 4.5 framework and runtime, put them into a separate assembly, and set a reference to it only when your project actually uses one of them.
|
|
|
|
|
David A. Gray wrote: I repeat: Stay away from the GAC.
I agree with that. Always seemed to me to be a solution looking for a problem that didn't exist.
|
|
|
|
|
Where do you think the framework assemblies come from? 
|
|
|
|
|
I know where the framework assemblies come from. The point is that you should think carefully, two, three, maybe even 4 times before you put one of your own there. Unless its usage is pretty much global in scope and it is stable, it belongs in the directory with the application EXE with which it shipped. Since .NET assemblies tend to be pretty small, compared to many native DLLs, this is not such a burden.
|
|
|
|
|
Yes you should think before using the GAC as it's probably not a good solution if your helper classes are volatile. I didn't tell him to put his classes in the GAC, I simply suggested it as an option to think about if he hadn't already. He is in the best position to decide if his classes are suitable for the GAC, not me and not you either If it's good enough for Microsoft I'm sure it's good enough for us too.
|
|
|
|
|
I agree. My comments about the GAC were aimed primarily toward lurkers.
|
|
|
|
|
F-ES Sitecore wrote: He is in the best position to decide if his classes are suitable for the GAC, not me and not you either
Most of the time an application developer should not be putting anything into the GAC.
That doesn't mean no one should ever do it but rather that they should only do it if they find that other solutions are not applicable.
|
|
|
|
|
F-ES Sitecore wrote: Where do you think the framework assemblies come from?
And device drivers live in a special realm as well.
But that doesn't mean I should make my banking application into a device driver just because it is possible.
|
|
|
|
|
jschell wrote: But that doesn't mean I should make my banking application into a device driver just because it is possible.
Putting helper functions into the GAC could well be a viable solution, I was merely pointing it out as an option, I wasn't telling anyone to do, or not do, anything.
|
|
|
|
|
F-ES Sitecore wrote: Putting helper functions into the GAC could well be a viable solution,
Unlikely and still not comparable when referring to "framework assemblies".
The comment stands - most of the time it is not a viable solution to put anything in there.
|
|
|
|
|
jschell wrote: Unlikely
That's your opinion based on zero intimate knowledge of the OP's code. As I've already said, it's not for me or you to decide, I made the suggestion for the OP to look into so he can make his own decision.
|
|
|
|
|
F-ES Sitecore wrote: That's your opinion based on zero intimate knowledge of the OP's code.
I have more than "zero intimate knowledge".
I know the code is being used by humans and non-technical ones at that. And users are copying it between machines. Thus the conclusion is that this is some UI application tool.
And for the scenarios suggested it makes it much less likely that the GAC should be involved at all.
|
|
|
|
|
jschell wrote:
I know the code is being used by humans and non-technical ones at that. And users are copying it between machines. Thus the conclusion is that this is some UI application tool.
I don't think that is "intimate knowledge".
jschell wrote: And for the scenarios suggested it makes it much less likely that the GAC should be involved at all.
If he hadn't considered the GAC before at least it is something he can think about now and make that decision for himself.
|
|
|
|
|
F-ES Sitecore wrote: I don't think that is "intimate knowledge".
With my decades of experience and given the original question that does in fact, to me, provide quite a bit of knowledge about the most likely scenarios.
|
|
|
|
|
You don't have intimate knowledge of his actual code though so you don't know if it is GAC suitable or not. All you can do is guess at a probability which is all well and good, but that's not something you should use to dictate solutions to people.
|
|
|
|
|
F-ES Sitecore wrote: but that's not something you should use to dictate solutions to people.
I suggest that you re-read the entire thread.
|
|
|
|
|
No need 
|
|
|
|
|
Bartosz Jarmuż wrote: - requires me to deliver a separate .dll file, which for some reason is much more difficult for users (they tend to share my programs without the .dll, which then crashes on startup)
As mentioned that isn't going to work regardless of what you do, because of the Net version dependency.
Bartosz Jarmuż wrote: I have a helper project which I use in all the applications that I create...I am the only person editing code
Where the plural "applications" means how many exactly?
And what size are the applications?
If there are only two or three and the apps are relatively small then don't use the dll.
If many applications or there are a few but big then use the dll.
The second case occurs because, despite your best intentions, it is more likely that you will break something by adding an improvement. Because of that handling the helper code as an independent delivery should continue to make you aware that changes can cause problems. And hopefully you should implement unit tests for the dll to insure that behavior doesn't change unintentionally.
The threshold for this becomes lower if another developer was added to the mix.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
