.NET (Core and Framework)

Jaime Olivares7-Sep-09 21:21

7-Sep-09 21:21

Hmm, not sure if it will be practical. Database approach is discarded, but embedding dlls into a single assembly can have some benefits. Still have to think on that, specially how to avoid to add complexity to the "consumer" code.

Best regards,
Jaime.

Eddy Vluggen7-Sep-09 21:45

Eddy Vluggen

7-Sep-09 21:45

Jaime Olivares wrote:
Hmm, not sure if it will be practical.

I found that multiple assemblies are more practical; you load the pieces you need, and keep 'em together in a folder. One could also compile everything into a massive DLL, but that's harder to update (you'd have to replace the entire thing, or overwrite a piece of it with binary data) and I doubt that .NET will optimize the memory-usage.

Jaime Olivares wrote:
embedding dlls into a single assembly can have some benefits.

For distribution, yes Smile | :)

I fail to see the advantages for a deployed application yet. Perhaps you can explain that a bit more in detail?

"If you automate a mess, you get an automated mess."

-- Rod Michael

Jaime Olivares8-Sep-09 3:03

8-Sep-09 3:03

Eddy Vluggen wrote:
One could also compile everything into a massive DLL, but that's harder to update (you'd have to replace the entire thing

That's the idea! I don't want to replace one or two dlls and leave others untouched. At some point, this becomes a mess which is hard to manage.

Best regards,
Jaime.

Not Active8-Sep-09 3:15

8-Sep-09 3:15

Jaime Olivares wrote:
At some point, this becomes a mess which is hard to manage.

How so?

Jaime Olivares wrote:
I don't want to replace one or two dlls and leave others untouched

If they haven't changed, why update them?

only two letters away from being an asset

Jaime Olivares9-Sep-09 3:03

9-Sep-09 3:03

I have dozens of products, all them sharing dozens of components. I can update a component that affect many products, of just specialized functionality that affects one specific product.
My intention is to have a secure distribution of the components' suite, prefereably as a monolithic big component, besides the specialized functionality that with a plugin approach.

Best regards,
Jaime.

Not Active9-Sep-09 3:39

9-Sep-09 3:39

Jaime Olivares wrote:
prefereably as a monolithic big component

Hello, the 80's are gone. This is the 21st century, time to update your skills for the real world.

only two letters away from being an asset

Not Active8-Sep-09 2:13

8-Sep-09 2:13

Jaime Olivares wrote:
I want to have a big single assembly with dozens of functionality groups, but I don't want them to be uploaded into memory until they are really needed.

You can't control this with a single assembly. The call to LoadAssembly works on a single file, not parts of it. The best way for this type of functionality is to use multiple assemblies and only load what is necessary. If you use separate AppDomains you can also cleanup unused assemblies and recover memory and resources if that is an issue. Some techniques that were used here[^]

only two letters away from being an asset

Jaime Olivares8-Sep-09 3:00

8-Sep-09 3:00

Multiple assemblies is exactly what I am trying to avoid because I have a dll hell. Consider a scenario with a dozen of dlls that are updated monthly. The single assembly points to reduce the risk of unsynchronized dlls.

Best regards,
Jaime.

Not Active8-Sep-09 3:13

8-Sep-09 3:13

Consider a scenario where you have a different architecture then. To my knowledge what you are asking for can't be done.

How large will this single assembly be? How large will it grow? If only one method in one class gets updated you have to recompile and distribute the entire assembly? Again, IMO, you need to reconsider this strategy. You are adding complexity to solve a simple problem.

only two letters away from being an asset

Jaime Olivares9-Sep-09 2:58

9-Sep-09 2:58

Hi again,

Mark Nischalke wrote:
How large will this single assembly be? How large will it grow?

Application can be about 10-20 MB executable, which takes even more when loaded on memory.

Mark Nischalke wrote:
If only one method in one class gets updated you have to recompile and distribute the entire assembly?

Yes and no. Just in few cases one method is changed, releases are frequent and many components are changed because all them are highly interconnected.
Updating just some components is always a risk and produces potential branching problem. A different combination of components is used depending on specific product.
So my intention is to release always the entire suite of components, prefereably in a single assembly.

Best regards,
Jaime.

Not Active9-Sep-09 3:36

9-Sep-09 3:36

Jaime Olivares wrote:
Application can be about 10-20 MB executable

Rediculus!

Enough said on this subject. Good luck Roll eyes | :rolleyes:

only two letters away from being an asset

Dave Kreskowiak9-Sep-09 6:33

Dave Kreskowiak

9-Sep-09 6:33

Jaime Olivares wrote:
releases are frequent

So you want the suer to download the entire "monolith" every time there's an update to a single method instead of a much smaller .DLL that encloses just the one component that was changed?? How much bandwidth are you allocating to this again?

Jaime Olivares wrote:
Updating just some components is always a risk and produces potential branching problem.

Only if you release components without testing them against the current versions of others.

Jaime Olivares wrote:
A different combination of components is used depending on specific product.

Then I guess you'll have to manage each site that the componet can be a part of. This will, of course, make your job a little hard because now you have to test each component against each application that it will be used in.

Jaime Olivares wrote:
So my intention is to release always the entire suite of components, prefereably in a single assembly.

Have you thought about packaging up all the related components into a .ZIP and having the app download that .ZIP and unpackaging it?

A guide to posting questions on CodeProject[^]

Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...

Jaime Olivares9-Sep-09 7:46

9-Sep-09 7:46

Dave,
Thanks for following, still want to explore all possibilities:

Dave Kreskowiak wrote:
So you want the suer to download the entire "monolith" every time there's an update to a single method instead of a much smaller .DLL that encloses just the one component that was changed?? How much bandwidth are you allocating to this again?

Bandwidth is not a problem, I can manage terabytes, literally. But a good patch algorithm can be applied to minimize this.

Dave Kreskowiak wrote:
Only if you release components without testing them against the current versions of others.

The proposal is to test the whole suite of common components first, and later the products. There are lots of implicancies when updating just single components. So the safest way to be sure is to update all them, without major analysis.

Dave Kreskowiak wrote:
Then I guess you'll have to manage each site that the componet can be a part of. This will, of course, make your job a little hard because now you have to test each component against each application that it will be used in.

The scenario is more or less the following: a single component suite in every machine, monolithic can assure 100% update. But still is just an option. Applications can be added to every station, or maybe they are already there, update of component suite and application should be independent. Even they are architectured to have a loosy coupling to avoid branching and versioning problems, due to high rate of updates.

Dave Kreskowiak wrote:
Have you thought about packaging up all the related components into a .ZIP and having the app download that .ZIP and unpackaging it?

Well, this is the obvious choice, even complies with the "monolithic" in some aspects, but I want to avoid the scenario where some dlls are updated and others aren't (it happens, for lots of reasons).

Best regards,
Jaime.

Eddy Vluggen8-Sep-09 3:38

Eddy Vluggen

8-Sep-09 3:38

Where are those assemblies installed? The best way to bypass Hell is by not going, and keeping all your DLL's in a single folder. That makes updating also easier; you just unzip and overwrite any existing assemblies.

That makes a small zip-package for easy distribution. No Hell, since all the assemblies are in a known location, all side-by-side.

"The best way to predict the future is to implement it."

-– David Heinemeier Hansson

Dave Kreskowiak8-Sep-09 4:43

Dave Kreskowiak

8-Sep-09 4:43

Then I would recommend that you include functionality that allows the application to update itself, checking the versions of .DLL's and comparing them against a website supplied database of current .DLL's and allow the app to download and update only those files it needs to.

A guide to posting questions on CodeProject[^]

Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...

Jaime Olivares9-Sep-09 3:08

9-Sep-09 3:08

Yeah, that's a possibility, but I want to handle the components as a monolithic product. I have many products that uses different components of this suite, but I want to be sure to distribute all them, so installing and activating new products will be a fast and secure process.

Best regards,
Jaime.

Not Active9-Sep-09 3:34

9-Sep-09 3:34

Microsoft came up with this scheme, perhaps you've heard of it it? Put shared assemblies into the GAC and specialized assemblies in the application path.

Jaime Olivares wrote:
I have many products that uses different components of this suite

Something like the Microsoft Office family of products? I wonder how they distribute everything? Roll eyes | :rolleyes:

only two letters away from being an asset

Dave Kreskowiak9-Sep-09 6:27

Dave Kreskowiak

9-Sep-09 6:27

OK, how many idfferent ways do you want to be told that piling everything into a monolithic .DLL is doing it the hard way?

A guide to posting questions on CodeProject[^]

Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009...

Jaime Olivares9-Sep-09 7:28

9-Sep-09 7:28

~~Dave,~~ Mark,
Your last 3 post are useless and lack of technical information. So I suggest not to follow "contributing".
This is a proof of concept. I am not looking for traditional solutions. I know all them.
Maybe you have not understood that this is a suite of highly complex products, with **thousands** of functionalities. Deployment and test cost million of dollars.

Sorry Dave, I have a mess of responses here. My last comment was for Mark.

Best regards,
Jaime.

Not Active9-Sep-09 11:06

9-Sep-09 11:06

Jaime Olivares wrote:
a suite of highly complex products, with **thousands** of functionalities. Deployment and test cost million of dollars.

As we have been saying. A huge monolithic deployment is not where you should be focusing, especially, given this information. It costs much more, in money and time, to support a monolithic application. Why do you think this type of application was abandoned long ago.

You break the functionality into smaller pieces so they can be developed and tested separately. Pick up some books on software architecture and design, ones published after the 1980's that is, and read how the rest of the software industry has been progressing, then maybe you can catch up.

Jaime Olivares wrote:
I know all them.

Enough said on all of this. You don't seem to want to listen to reason or advise so good luck Roll eyes | :rolleyes:

only two letters away from being an asset

Jaime Olivares9-Sep-09 11:21