Partial assemblies

[Andrus]

I need to add methods without subclassing to run time compiled assembly at
design time so that reflection also works .

I need to define single type methods in two assemblies.

I created project1 containing

public partial class Class1 {
public string Test1() {
return "";
}
}

and project2 containing

public partial class Class1 {
public string Test2() {
return Test1();
}
}

and added reference to project1 into project2.
Building solution causes error

The name 'Test1' does not exist in the current context

at line

return Test1();

How to fix ?
How to use this type of class extension ?

Andrus.

 

[Jon Skeet [C# MVP]]

I need to add methods without subclassing to run time compiled assembly at
design time so that reflection also works .

You can't do so.

How to fix ?
How to use this type of class extension ?

You can't. There's no such thing as a "partial assembly". Partial types
are entirely a compile-time business in the first place - the CLR has
no concept of it.

 

[Alun Harford]

I need to add methods without subclassing to run time compiled assembly at
design time so that reflection also works .

I need to define single type methods in two assemblies.

I created project1 containing

public partial class Class1 {
public string Test1() {
return "";
}
}

and project2 containing

public partial class Class1 {
public string Test2() {
return Test1();
}
}

and added reference to project1 into project2.

There is no easy way.

I suppose you could make the two assemblies and have a bootstrapping
module which takes the two assemblies and combines them.

You'd need to:

1) Add all the methods into a single class (perhaps using attributes to
indicate which classes should be combined, or just requiring them to
have the same name and be in the same namespace).

2) When you add methods to the new assembly, you'll need to modify the
IL so that method calls point to the method in the new assembly.

Debugging could quickly become very painful though.

Alun Harford

 

[Marc Gravell]

Not question specific, but can I suggest something? Based on the
series of questions (over the last 2 months or so?) it seems that to
meet your intended design, you are currently having to fight the
system at almost every stage. Perhaps this simply isn't the right way
to do it? It shouldn't be this hard! And no, unfortunately I don't
have any magic advice: "do it this way and all shall be grand"...

Now, *possibly* LINQ-to-Entities will (when released) make a viable
alternative to DbLinq (which I believe is part of the issue relating
to property-order/reflection), but hard to tell at this stage...

But there's a lot of things here (esp. the runtime code creation/
inheritance) that are going to make this very hard to support, and (I
would hazard) quite brittle.

Just a thought...

Marc

 

[Andrus]

Marc,

Not question specific, but can I suggest something? Based on the
series of questions (over the last 2 months or so?) it seems that to
meet your intended design, you are currently having to fight the
system at almost every stage. Perhaps this simply isn't the right way
to do it?

The questions I posted represent the issues I encountered.
Currently I have application prototype which allows to define properties in
runtime, uses virtual grid for editing List<Entity> data sources. It seems
to be possible to use .NET.
I'm trying to find the limits of .NET using probing to get max from it.

Java has more ready to use open-source components for ERP line OfBiz
framework and even full application, ADempiere. Unfortunately I havent seen
any open-source component in .NET for ERP like OfBiz in Java.

It shouldn't be this hard! And no, unfortunately I don't
have any magic advice: "do it this way and all shall be grand"...

My first prototype was using NHibernate/Castle ActiveRecord .
I ported it to DbLinq. Currently it seems this was right way. It seems that
Linq is better than NHibernate:
is has better documented, I can get more support, I must debug only driver
code (some thousands lines) which is a much less that NHiberante/Castle
(half million lines).

Now, *possibly* LINQ-to-Entities will (when released) make a viable
alternative to DbLinq (which I believe is part of the issue relating
to property-order/reflection), but hard to tell at this stage...

My customers use Linux/NetBSD for 15% .. 50% of servers. I use PostgreSQL
dbms.
LINQ-to-Entities seems to support only MS SQL.
It's architecture does not allow to create drivers for other databases like
Linq.
It even has specialized SQL language dialect which gets converted to MS SQL
server on the fly.

I read the LINQ-to-Entites FAQ but did'nt understand how to use it in my
application.
So I'm trying to create my own entity layer based on Linq.

But there's a lot of things here (esp. the runtime code creation/
inheritance) that are going to make this very hard to support, and (I
would hazard) quite brittle.

My prototype uses runtime code generation. I havent tested this part
extensively but it seems to be possible, 5000 lines of c# code seems to be
created from existing assembly and compiled fast in my 1.7 Ghz notebook,
custom columns can be retrieved using Linq.
If inheritance is implemented generated code is reduced to less than 500
lines in most cases.

Linq-SQL supports inherited entity class IFAIK.
George will try to replace parameterized contructors usage in DbLinq code
tonight so I expect DbLinq should support it also.

Andrus.

 

[Marc Gravell]

LINQ-to-Entities seems to support only MS SQL.

It's architecture does not allow to create drivers for other
databases like Linq.
It even has specialized SQL language dialect which gets converted to
MS SQL server on the fly.

LINQ-to-SQL is specific to variants of SQL Server; however, my
understanding is that the entity framework (the big brother of
LINQ-to-SQL) *will* support *some* other databases. I can't remember
the "who" etc, but I seem to recall this being stated pretty clearly
at TechEd amongst other things. I don't know which other databases
will be supported, however IIRC it might be Oracle, DB2, SQL Server
and Sybase. But I also understand that (unlike LINQ-to-SQL) this is
provider-extensible.

As you have discovered: the entity framework is complex. I've watched
videos, demos etc, and read the documents and I only really understand
bits of it. I'm waiting until it is RTM before I try again to
understand it... (currently Beta 3)

Again, *and I stress*: this is all just from memory; I don't pretend
to represent the ADO.NET (ets) team(s). However, you might be able to
get direct answers to all this (and more) at the LINQ project forum:

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=123&SiteID=1

Marc

 

[Andrus]

Marc,

As you have discovered: the entity framework is complex. I've watched
videos, demos etc, and read the documents and I only really understand
bits of it. I'm waiting until it is RTM before I try again to understand
it... (currently Beta 3)

Thank you for remembering the complexity.
I understand now that I forgot one major argument against entity framework :
running under MONO.
MONO C# 3 compiler is nearly complete. There are .NET 3.5 linq libraries in
Olive project in pre-alpha. So I expect that application using .NET 3.5 linq
assemblies and .NET 2 WinForms can run in MONO in foreseeable future.

I do'nt see how application using Linq-to-entities can run in MONO in
foreseeable future.
Using Linq-to-entites assemblies will not be allowed in Linux. There are no
attempts to clone it as far as I know.
So I can try learn and understand it, but not to use.

Andrus.

 

[Sébastien Ros]

I think it's possible using AOP techniques. You should look at the Mixin
concept which is relatively close to what your are descibing (yet different).

A technical solution I suggest is to use the open source library named Cecil
(http://www.mono-project.com/Cecil) which is able to do these AOP techniques.
Thus you can open the assemblies and fusion your classes into a new one or in
an existing one. An attribute could be placed on one of the classes to
describe the link, and let a tool fusion all related classes automatically.

The only drawback is that it can only be done after compile time. At least,
using an interface could be a solution to it.