|
Roger - the rewrite of .NET 4 meant that they distributed a completely new version because they put a lot of effort into making the runtimes smaller, reducing memory bloat. If you installed .NET 3.5, it was merely an extension to .NET 3 which, was an extension of .NET 2 - so they merely added new DLLs in those versions.
I hope that this clears any confusion up.
|
|
|
|
|
Pete,
I am still a bit confused.
Are you saying .NET 4 does not have all the dlls from the previous versions?
Thanks in advance!
|
|
|
|
|
That's exactly what I'm saying. While it has all the functionality, some of that functionality was moved between DLLs. Remember that the DLLs also have security in them to prevent them being tampered with, so each new version of the DLL gets a new security ID.
|
|
|
|
|
As I explain to Roger below, you may just need to change the reference from a .NET 3.5 DLL to a .NET 4 DLL to get it working OK.
|
|
|
|
|
I'm not criticizing the .Net 4 distro, but it still leaves Lydia hanging - she needs stuff in 3.5 that was left out of 4, apparently. As much as I dislike Microsoft's way of doing business, they have been really good about including all the dependencies in previous rewrites, and it seems that they didn't do so this time. Of course, I'm relying on adubious source[^] and could be entirely confused.
Will Rogers never met me.
|
|
|
|
|
Take a look at the criticism section which show that Microsoft were damned if they did and damned if they didn't:
"Some developers have expressed concerns about the large size of the .NET Framework runtime installers for end-users. The size is around 54 MB for .NET 3.0, 197 MB for .NET 3.5, and 250 MB for .NET 3.5 SP1 (while using web installer the typical download for Windows XP is around 50 MB, for Windows Vista - 20 MB). The size issue is partially solved with .NET 4 installer (x86 + x64) being 54 MB and not embedding full runtime installation packages for previous versions."
Basically, the issue they are addressing here is the user experience when somebody has to download code written for .NET 3.5 SP1 which resulted in a whopping 250MB download. What it sounds to me is Lydia has code that is still using a .NET 3.5 reference (in VS2010 you have the option just to choose .NET 4 references). The fix could be as simple as removing the reference to the old DLL and adding in the appropriate .NET 4 version.
With .NET 4, it's not a good idea to mix with previous versions.
|
|
|
|
|
Pete O'Hanlon wrote: The fix could be as simple as removing the reference to the old DLL and adding
in the appropriate .NET 4 version.
Good point; removing functionality that is dependent on a previous version and replacing it with more current versions might remove a lot of challenges.
Will Rogers never met me.
|
|
|
|
|
Thanks for your replies and useful tips Roger and Pete!
|
|
|
|
|
You are welcome, and good luck.
|
|
|
|
|
You're quite welcome! 
Will Rogers never met me.
|
|
|
|
|
Actually, if you are compiling against .NET 3.5 so that your code works with 3.5 AND 4.0, then the issue is likely that you are using server-side components.
.NET 4.0 is broken up into a Client Profile and Extended versions.
.NET 4.0 by default only installs the Client Framework when installed on a client machine. Server-side (defined by Microsoft) components are not included (to keep the install size down). You can install them with the .NET 4.0 EXTENDED Framework, after which I would expect your service to work.
If you set your compile target to .NET 4.0 Client Profile, you can discover which components are missing (because they are only in extended in 4.0), and possibly remove them if you want it to work with the 4.0 Client Profile.
|
|
|
|
|
Since your application is compiled for both .NET 3.5 and 4.0, you will need both installed. If you want to run on a system that only has 4.0 installed, you will need to recompile all of your projects (of the service or application) using .NET 4.0. Look at all of the responses for more ideas.
|
|
|
|
|
I am developing a system that I'm trying to keep as generic as possible.
It is capable of implementing/executing business rules that should be defined in another file/assembly.
For sake of explanation, I'll segment the idea into the "generic system" and "business system".
If the "business system" were to change or require an update, then that should be possible without releasing the "generic system".
Let's say the generic system monitored a folder, and if a file associated with the new version of the business code was dropped into that folder then it would be accessed, and if the version was > than the current one, then the generic code would start using it.
The business code could have a factory method like GetEventProcessor(guid) that would return a delegate (from the "business system" (with a consistent signature) that is associated with the guid passed into GetEventProcessor.
I'm looking for examples of or ideas about a mechanism whereby code with a defined interface can be picked up and integrated into execution of another piece of code at run time.
I have found some articles about plug-in based architectures in .net. Developing this type of system is new to me, and as I peer down the barrel of this possibility, I thought I'd pose the question here in hopes of harvesting some opinionated  guidance, warnings and/or advice.
Any ideas are welcome.
Thanks
Todd
|
|
|
|
|
|
Presumably there is a business reason driving this.
First step is to define exactly what a 'rule' does. It can't do everything in the known universe because it isn't possible for a consumer to code to such a requirement. So it has to be restricted to some sort of interface (not necessarily meaning the keyword but possibly meaning that) which the consumer knows how to use and manage.
That is a design step not an implementation step.
After you know what that looks like then you might want to look at the Microsoft Addin.
http://msdn.microsoft.com/en-us/library/gg145020.aspx[^]
Although it might be better to write one yourself.
|
|
|
|
|
todd.01011101 wrote: I'm looking for examples of or ideas about a mechanism whereby code with a
defined interface can be picked up and integrated into execution of another
piece of code at run time.
Most KISS solution I can come up with would be an application that simply polls the directory and which processes every file - getting the processor based on the extension of the files. Aw, the most KISS-way of building a processor would be a console-application that generates output, simply passing the path as an argument.
Would be quite easy to maintain and extend, in any language
Bastard Programmer from Hell 
|
|
|
|
|
Since you are planning on versioning your logic, you will run into a .NET limitation that you cannot unload code once it is loaded into an app domain[^]. This is regardless of the plug-in discovery mechanism that you choose.
One way around this limitation is to run your plug-ins in separate app domains, unloading the entire app domain once you need to load the next version of a particular plug-in.
Since you cannot make plain old calls across app domain boundaries, so you'll need to design your interface carefully to avoid spending excessive time serializing and deserializing parameters and return values.
Here is the method I use to access items loaded into separate app domains: CreateInstanceAndUnwrap[^].
|
|
|
|
|
I don't expect *too much* churn of the plug-ins, (1, maybe 2 in a day) and the app domain is cycled every night by default so I'm not too worried about the old plug-ins stacking up and causing memory/performance issues. (If I've misinterpreted the outcome of the limitation you described, please set me straight).
That being said, thanks so much for your answer. I'm so glad I posted this here, I've got some great information, and great leads to follow.
I've been reading with eyes wide open all afternoon.
Todd
|
|
|
|
|
todd.01011101 wrote: I don't expect *too much* churn of the plug-ins, (1, maybe 2 in a day)
Every day?
Or when it occurs every 6 months it might involve 1/2?
If the first then perhaps you should look into some entirely different options such as scripting.
|
|
|
|
|
Yes, I meant that the maximum would be 1/2 in a day, but maybe once every few months.
Certainly not 1 or 2 every day.
|
|
|
|
|
You could look at writing dynamic assemblies or methods Using Reflection Emit
"You get that on the big jobs."
|
|
|
|
|
Ok, but how would you know what code to create dynamically? You would still need a mechanism to define the logic so it could be created dynamically. Sorry, not a very good suggestion for the problem, there are far easier methods that are more performant.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
I have used Castle Windsor[^] to accomplish something similar. There are several other .NET inversion of control containers that may also work (StructureMap, Spring.Net, Ninject, etc.) but I don't have any experience with them.
Regards,
Eric
|
|
|
|
|
Given your rate, 1/2 every 6 months, I doubt a generic system is going to provide an advantage.
|
|
|
|
|
What about a scripting engine for the business system/ part of the business system. If you require functionality to be dynamic. It could be scripted and changed on the fly.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
