|
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?
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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? 
only two letters away from being an asset
|
|
|
|
|
OK, how many idfferent ways do you want to be told that piling everything into a monolithic .DLL is doing it the hard way?
|
|
|
|
|
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.
|
|
|
|
|
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
only two letters away from being an asset
|
|
|
|
|
Mark Nischalke wrote: You break the functionality into smaller pieces so they can be developed and tested separately.
Yes, and that's exactly the problem, when you break them into smaller pieces (dozens), then you have a hell of versions that generate totally unexpected defects (not the folder/dll hell, btw) when trying to communicate one with each other.
Mark Nischalke wrote: 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.
Already did that. This just tell me about the main streamline. For this kind of research, academical papers is a better choice, already read some of them too.
Mark Nischalke wrote: Enough said on all of this. You don't seem to want to listen to reason or advise so good luck
I don't want to know about industry trends, because I know them, I have enough books and RSS suscriptions. I am researching for alternatives.
Best regards,
Jaime.
|
|
|
|
|
Is there a way to draw lines , shapes ... in Visual Studio 2005 in design-time ?
|
|
|
|
|
|
|
I build application in vb.net 2005. Now i want to deploy it through setup (build through setup and deployment project in vb.net),
I want to install sql server2005 express with my setup if anyone know, please help me and tell me the complete steps.
|
|
|
|
|
|
Hi All,
i have developed a windows application and i have create the setup for the application. But my problem is how can i add a icon/image in that setup file.for example for sqlserver setup they had their own icon,for VLC player setup they had their own icon..I also want my setup has my own icon.
Plz tell me...
Thanks,
Sk inayat.
|
|
|
|
|
|
thanks for ur post, but it was not working....
|
|
|
|
|
I want something like paper forms that is filled by hand, in my program. The filled form should be stored as a field of type binary in the database. What I need is a framework for making and presenting those forms;for example as a word document...
I want the forms to open without the need for a software(e.g. like word office) . The form should be opened in a .NET windows form and changed there.
|
|
|
|
|
|
InfoPath ?
only two letters away from being an asset
|
|
|
|
|
Whatever name . Just a clean solution. I dont want to engage in its complexities.
The font and layout of the form should be fixed and the user would just type in tables' cells and not be permitted to change the layout. No toolbar for changing fonts and the like is needed just typing should be allowed.
If you are a girl ... then ...
|
|
|
|
|
Another option is to use a PDF library to display the form with edit fields. Of course you can alwasy just create your own windows/web form.
You don't need to store the form in a binary format in the database, only the data that was entered.
devboycpp wrote: Whatever name . Just a clean solution. I dont want to engage in its complexities.
Since we know nothing about your requirements or constraints for the project we can only offer suggestions. It's up to you to determine which is the best method.
only two letters away from being an asset
|
|
|
|
|
Mark Nischalke wrote: You don't need to store the form in a binary format in the database, only the data that was entered.
Dude , the reason why I want this is because the fields of the form are many (almost 130 ). The data in fields are all of varchar type. I go crazy having to make a table with 130 fields and a form to show those fields , a stored procedure to update , insert to those fields.
Do you have a more elegant way ?
|
|
|
|
|
Then what happens when the form changes? The previous versions you have stored are all invalid?
A more elegant solution would allow the data to be stored independent of the presentation.
I'm sure this data could also be used for analysis also, forming charts or graphs. It wouldn't be possible in a binary format.
devboycpp wrote: The data in fields are all of varchar type.
Are the fields truely all varchar, or are you being lazy and making them such? What about validation of the data entered?
If they are all truely varchar then a table could be constructed with a name/value pair. With an identity column, that's only three columns. Is that too much for you?
If they are not all varchar and you need to create a table with seperate columns, using Linq to SQL or Entity Framework you can eliminate the need to write and maitain stored procs. Also, I'm sure there is potenttial to normalize the data and elimiate some of the columns.
Lastly, don't call me dude.
only two letters away from being an asset
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
