shennig wrote:
Walaa wrote:
This is indeed unfortunate. the 'design' stuff is in the same assembly and the web stuff is also in the same assembly so unfortunately your clients have to use the full .net framework. Removing the design stuff and datasourcecontrols from the ormsupport classes is a lot of work.
Why is the 'design' stuff needed for the ormsupport classes at all? in the namespace design are things for user designes components, where is the relation to an or-mapper?
When you add an EntityCollection to a windows form, and you want to design the grid bound to it in vs.net. At that point, the entity collection is 'ran' by vs.net's designer canvas, but not fully 'ran' in the sense that it is in an application, so it has to know if it's used at design time or not. How to do that? Well, to be honest, there's not a lot of documentation on that subject, so we decided to use what worked: a flag in the designer for the entity collection class.
Keep in mind that it took a lot of work to make this design time stuff work with the runtime lib classes in all possible cases, so that for example lazy loading is switched off in selfservicing etc. as vs.net simply creates an instantiation of the form and runs the code inside the designer of vs.net.
Is there really no work around????
I'm afraid there isn't. Keep in mind that this slimmed down version of the .net framework is what Microsoft thinks is what users will need. Every assembly used which refers to something which is a normal .net class but which is inside an assembly which isn't in that streamlined set will have a problem.
You mentioned this term, it was the first time I saw it btw. Why is this a big problem btw? The .NET framework is widely spread already.
