|
Thank you, I finally solved it 
|
|
|
|
|
Hello,
I have a question - I have a helper project which I use in all the applications that I create. It contains some extension methods and a bunch of generic helper classes, controls etc. I update /extend the helper project from time to time.
I tried two approaches for using it
1) add .cs files directly (Add as link) to each project where I use them
2) compile it as .dll and add it as reference
I see some benefits and drawbacks of these approaches.
The first one:
+ is simpler, because the helper classes get compiled into the exe file, therefore I can often very easily provide just a single .exe file that will work just fine. Because I add as link, I can be pretty sure that whenever I build any project that uses the helper, the helper files will be the latest version.
+ is even simpler, because I can separate the files, so that my extension methods that run fine on .NET 4.0 can be referenced separately from the ones that require .NET 4.5, which means that the app as a whole can run on .NET 4.0
- doesnt seem to be 'best practice'
The second one:
+ appears to be the right approach, but:
- 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 it gets compiled into a single .dll, it will require the highest version of .NET - many of my users don't have .NET 4.5 and only some elements of my helper class require this, which means I can be forcing some people to update their systems for no reason
- I also need to make sure that whenever I update any of my programs, I also deliver the .dll file - even though I don't know if it has been changed since the last version, or not (it could have been, but it could as well be the same version). I cannot see a simple way to determine that, without keeping track of assembly version, which is additional work. For now, when I update my programs, I only deliver updated exe, and I like to keep it small and low profile.
So, what is the actual benefit for using the .dll file here? Please note, that I am the only person editing code of all the applications and the helper files.
Thanks in advance for your opinions!
|
|
|
|
|
The second one is the right one: it means that you can fix bugs and release the latest version without having to rebuild the application(s) that use it. It also means that the "consumer" of the helper classes can't change the way they work and nobody knows.
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)
So issue your application with a setup program - because that also makes sure that the correct version of the framework is installed. Would you copy "Word.exe" from one system to another and expect that to work?
Bartosz Jarmuż wrote: s it gets compiled into a single .dll, it will require the highest version of .NET
Why? It will need the highest version of .NET that will run the code within the DLL, not the version that your app uses.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Quote: Why? It will need the highest version of .NET that will run the code within the DLL, not the version that your app uses.
Hm, I was under an impression, that if I reference a .dll file into my project, and that .dll has code that requires .NET 4.5 then the whole app needs to be built for .net 4.5
As for the setup project, yeah, I started doing that some time ago (exactly because of .net auto-check), but it's quite a lot of additional work (create the project, set all properties etc), which is tiring for a 40kb program.
Quote: it means that you can fix bugs and release the latest version without having to rebuild the application(s) that use it. It also means that the "consumer" of the helper classes can't change the way they work and nobody knows.
What's the harm of rebuilding the app that uses it? 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...
Thanks a LOT for your comments!
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
