Can I reference a struct outside my DLL?

I'm creating a DLL to use in another application.

I have a struct full of different variables.

I want to create a new instance of this struct within different classes I have inside the DLL.

I then want to reference or access these variables within this struct outside the DLL by way of an interface calling a function that returns the struct.

Can this be done??

I successfully return other data types using an interface, but can't use the same syntax to return my struct. I can't even initialize my struct in the scope of a class (as I can with other data types).

Can what I'm tyring to do be done??

Please refer to the DLL as a 'class library' or 'assembly' (they aren't called Dlls anymore in .Net).

I mention this because I want to be sure we are on the same page for what you are trying to do. I am going to assume that you have started by creating a 'class library' project and want expose a struct inside a class library.

For this to be visible, you need to mark the struct as public (i.e public struct Foo { }).

In the application where you want to use the struct, you need to add a reference to the class library that contains the struct. To do this, just right click on the References node in the solution explorer and choose 'add reference'.

There are several tabs that open. You can browse to the assembly or choose one from another project that's in your solution.

Next, in order to use the struct inside the code, you need to include the namespace for the class library (e.g. using MyClassLibNamespace;).

I appreciate the help, thanks. Maybe I should have complained to the fact I was trying to access my Class Library within a C++ application. I have, however, made a work-a-round.

Code:

---


// my interface giving public access from outside the library
public interface IClass1
    {
        // my function that performs the routine
        void Function1();     

        // my functions that returns values
        double Value1();
        int Value2();
        string Value3();
    };


// my public struct accessible throughout any class within my library
public struct myData
    {
        public int iX;
        public string sY;
        public double dZ;
    };


// my class inherited from my public interface. Executable code goes here.
public class myClass1 : IClass1
    {
        private myData sData;  /* created a struct type variable within scope of class */

        // simple public functions to return private variables
        // This is my work-around since I could not return a struct data type
        public int Value2()                { return sData.iX; }
        public string Value3()              { return sData.sY; }
        public double Value1()              { return sData.dX; }

        // the public function made accessible outside the class library
        public void Function1()
        {
              // be sure to assign the values to the local struct instance
              sData.iX = 123;
              sData.sY = "Person Name";
              sData.dZ = 987.369

              // enter rest of your code here to run routine when called
        }

        // a private function not seen outside the library, but visible within this class
        private void Function2()
        {
              // another function within this class to perform another routine

              // use any variables defined within class or create local variables
        }

    }

---

This was my solution to my problem... and It Worked!

Quote:

---

Originally Posted by Arjay

Please refer to the DLL as a 'class library' or 'assembly' (they aren't called Dlls anymore in .Net).

---

Crap! I hate it when I'm the last to know something. Whoever thought of not calling them dll's anymore ought to change their file extension to convey that.

I think there's a subtle difference between assemblies and DLLs, a DLL is a module (as it has always been) and an assembly can consist of one or more modules.

the file type is a dynamic link library regardless of what it contains. what it contains is either a module, assembly, resource, or whatever else we choose to place in it.

being that typical .net exe's and dll's are not native images like a dll from C/C++ I think there could be an argument for making them separate file types instead of reading for a header value in each exe or dll to know whether to compile it or not.

you can rename a .exe to a .dll and use it as a reference, so there's no exporting that would normally take place for a dll in other languages, so IMO the "boundry" between a "class library" "console application" and "windows application" are identical outside of the extra platform calls that are performed to initialize / create a console window in a console app.