locked
The type 'library' is defined in an assembly that is not referenced. You must add a reference to assembly

    Question



  • Hi,

    I am developing an windows form application. This has an Data Acces Layer and an Entity layer.

    On the first one I have an EntityManager class which has generic code to excecute data base transactions. There is also a class called DB_DataField and another one called DB_DataTable. Those have only some properties.

    On the Entity library I created a simple object which inherits the EntityManager from the DataAccessLayer. It has 3 attributes:

    2 DB_DataField = represent the columns on the table
    1 DB_DataTable = represent the table

    Then I created a console app just to test everything, this is the code:

    TestEntity test = new TestEntity();

    test.EcfName.Value = "test1";

    test.Insert();// this insert method is inside the EntityManager class but test inherits EntityManager.

    Console.WriteLine(test.EcfId.Value + " " + test.EcfName.Value);

    When a try to compile the whole app I got this error:

    Error    2    The type 'DataAccessManager.EntityManager' is defined in an assembly that is not referenced. You must add a reference to assembly 'DataAccessManager, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.    C:\Development\Projects\VS NET\QMSoftware\Libraries\ConsoleTest\Program.cs    12    13    ConsoleTest

    It works only if I add the reference to this project....but the thing is that I just need to use the Entitylayer because it already has inside a reference to DataAccessManager....I that is the idea to have separate projects....as long as I know...I am not a pro........I am using VS 2008 and this project is based on one I have developed on VS 2005 and the 2005 version it did work so.

    Can any body help or does anyone have a suggestion?
    Tuesday, February 26, 2008 6:14 PM

Answers

  • LINQ to SQL only works with MSSQL, but LINQ to Entity Framework will be out sooner or later.

     

     

    What I posted was just how I would approach the problem of representing a property as having a relationship with a data column. I mapped most of the properties in your class to it. Of course, there's more work in making that a reality. You need to make an Attribute class and make your EntityManager able to handle it. I think LINQ to SQL does something similar, and ORM just means Object-Relational Mapping (which you're doing as well).

    Wednesday, February 27, 2008 8:27 PM

All replies

  • Every project needs and must have its own references.  Solutions do not have references.  Solutions contain one or more projects, and provide an useful means to coordinate how mulitple projects interact with each other; i.e. build order and dependencies.  Solutions do not interfere with inner workings of individual projects.  Ever.

     

    Rudedog

     

    Tuesday, February 26, 2008 6:31 PM
  • One thing to keep in mind in layered development is that a layer should only be aware of the classes in it's own layer and the layer immediately below it. A layer should never know about objects in the layer above it. I think you should move EntityManager into the Business (or Entity) Layer. ORM is contained within the business layer since it's hydrating entities and therefore needs to know about them.

     

    Typical three layers:

     

    Presentation (or GUI)

    Business (or Domain)

    DataAccess (or Persistence)

     

    Here's a great resource (though I disagree with their assessment that the DAL will return business entities, it should return the objects to map to business entities):

     

    http://msdn2.microsoft.com/en-us/library/ms978689.aspx

    Tuesday, February 26, 2008 11:12 PM
  • Hi Rudedog, thank you for your answer but I did not mention anything about references between solutions..... I did not event mention the word Solution on my thread.

    But I thank you any way to take time to answer me.
    Wednesday, February 27, 2008 8:55 AM

  • Hi Chris, thanks a lot for your answer.

    I totally agree with you....but first I am not using any ORM and second, my idea is that the next developer will have only to create a new entity which inherits the EntityManager I have created and that's it. With this, the developer won't have to type any sql statement because everything is on the EntityManager class.

    Instead of using normal types for the attributes of the class, the developer will have to use this DB_DataField Class. This class has these attributes.

    private string  strColumnName;          //Column´s name
    private string  strColumnPrefix;          //Column´s prefix
    private DbType  dtpColumnType;       //Column´s type
    private bool    blnIsNullable;              //Specifies if the column allows null values
    private object  objValue;                   //Column's value
    private bool    blnIsForeingKey;        //Specifies if the column is foreing key
    EntityManager eeForeingEntity;        //Specifies from which entity comes the foreing key

    So the main thing is that the developer has not to worry about typing sql statements what he has to worry about is to create entities, that is the reason why I want to have the EntityManager on a diffrent library. So the developer does not have to even think about the EntityManager, he has just to add a new reference from the library.

    I do not know if that is a good idea...I find a little bit #%&$$/ to be typing sql statement when they are always the same....

    Could you please give me some advice about it....or tell me what you think about my idea.

    Thanks a lot

    Wednesday, February 27, 2008 9:13 AM
  • I think if you're actually using stuff defined in the base class it will require you to pull that library in.

     

    Before I criticize your idea, let me preface it by stating that I think LINQ to SQL is awesome if you're in VS 2008!

     

    So, the idea you have is sound. But, I would not have used the DB_DataField or similar class. I would have made attributes, since I would want the entity objects to appear "normal" to the developers using those entities. Something like this:

     

    [DataColumn(Name = "Name", DataType="varchar", Nullable = false)]

    public string Name { get; set; }

     

    Wednesday, February 27, 2008 4:29 PM

  • The thing is that I want this project to work with any data base...I hava change the code of the enterrprise library so it can work with MSSQL, ORACLE, MYSQL, Postgre....of course I used some internet resourses.

    I know linq is very good but it works only with MSSQL...and that is not what I want......

    [DataColumn(Name = "Name", DataType="varchar", Nullable = false)]

    public string Name { get; set; }


    what is that...is that Linq......ORM?........that looks very good....

    Thanks a lot for your reply
    Wednesday, February 27, 2008 7:37 PM
  • LINQ to SQL only works with MSSQL, but LINQ to Entity Framework will be out sooner or later.

     

     

    What I posted was just how I would approach the problem of representing a property as having a relationship with a data column. I mapped most of the properties in your class to it. Of course, there's more work in making that a reality. You need to make an Attribute class and make your EntityManager able to handle it. I think LINQ to SQL does something similar, and ORM just means Object-Relational Mapping (which you're doing as well).

    Wednesday, February 27, 2008 8:27 PM