How to create a DLL that can be called from another Win32 appl.

  • Thread starter Thread starter Claus
  • Start date Start date
C

Claus

Hi all,

I am new to C#, .NET and Visual Studio but I have been coding professionally
for more than 10 years, so I am not a complete newbe :-)

At my work we are now in the process of switching from Borland Delphi to
Visual Studio and C#.
We have a lot of applications that we do not have time to recode to .NET, so
we are planning to do all "new" developments in C#.
And this is where my question pop up:

I need to create a new Database Search form for one of our apps. and I would
like to do this in C#, so that later developments in .Net can reuse this.

How can I create a DLL that can open a WinForm and return a string (as soon
as I got this in place, I can start doing real stuff :-))
Another Win32 (un-managed) appl. should use this DLL.

Since this is my first C# project, I need information about all the steps
necessary to do this.



I hope you are able to provide me with guidelines and if possible some
samples.

Thank you very much in advance

/Claus
 
Claus a écrit :
I am new to C#, .NET and Visual Studio but I have been coding professionally
for more than 10 years, so I am not a complete newbe :-)

At my work we are now in the process of switching from Borland Delphi to
Visual Studio and C#.
We have a lot of applications that we do not have time to recode to .NET, so
we are planning to do all "new" developments in C#.
And this is where my question pop up:

I need to create a new Database Search form for one of our apps. and I would
like to do this in C#, so that later developments in .Net can reuse this.

How can I create a DLL that can open a WinForm and return a string (as soon
as I got this in place, I can start doing real stuff :-))
Another Win32 (un-managed) appl. should use this DLL.

Since this is my first C# project, I need information about all the steps
necessary to do this.



I hope you are able to provide me with guidelines and if possible some
samples.
Click to expand...

Hi,

Basically, I think you cannot create DLLs in .NET in the usual sense.
What you create are called Assemblies (that are confusely named *.dll).
But you can use the libraries you create via COM (cf.
ComVisibleAttribute), which I hope can solve your problem here.

Mathieu
 
Hi Mathieu,

You can write a function inside the DLL that creates a new Form object and
then calls:

Objectname.Show();

Expose this function as a public function. You can add additional parameters
that you want to pass in the function definition and by returning a
collection type from the return clause you can receive strings et al.

Seek me if you want more help.
 
Dear Radhakrishna ,

That is exactly what I am after :-) I got this code working (see buttom):

But I would like to create a new Form1, and design with all necessary
components and code.

What are the tasks to compile multible sourcefiles (class1.cs and form1.cs)
and strongname these, to be able to call from un-managed code?

* For startes: how do I compile Class1.cs AND Form1.cs into TestDLL.dll from
the command line?


Thank you for your help

/Claus


using System;
using System.Reflection;
using System.Runtime.InteropServices;
using System.Windows.Forms;
using System.ComponentModel;
using System.Text;

namespace TestDLL
{
public interface MyInterface
{
void myMethod1();
void myMethod2(string msg);
void myShowForm();
}

[ClassInterface(ClassInterfaceType.None)]
public class MyClass : MyInterface
{
public MyClass()
{
}

public void myMethod1()
{
MessageBox.Show("Hello World... Calling from C#");
}

public void myMethod2(string msg)
{
MessageBox.Show(msg);
}

public void myShowForm()
{
Form myForm = new Form();
myForm.Show();
}
}
}







"Radhakrishna Banavalikar"
 
Claus said:
At my work we are now in the process of switching from Borland Delphi to
Visual Studio and C#.
Click to expand...

We're also doing this, but I can't imagine any GOOD WAY to call .NET
Windows forms or dialogs from a Delphi Win32 application. This would
require hosting the CLR inside your Win32 process and this can get
nasty quick.

We've separated our visual components by platforms and we don't re-use
them between Delphi and C#. But we have a lot of middle tier Delphi
business components where
we added a COM interface to them so we can call them from C# (we just
use a RemoteDataModule on the Delphi side).

Conversely, we also have some new C# business objects that we surface
to COM+ by descending from ServicedComponent. Then Delphi can easily
call them.

We also make calls across servers and we're using a customized version
of Borland's Socket Server to do this. This lets us marshal the COM
calls over a TCP/IP socket, and it also provides for round-robin load
balancing. We also added some functionality Borland had in their legacy
OleEnterprise product that lets us control which servers are allowed to
"export" which components - this allows dynamic reconfiguration without
bringing anything down.

We also use both Delphi and C# in web applications, both legacy ASP and
ASP.NET. Again, COM is the key to easy interop. You could look into
p-invoke for a faster way to call a Delphi DLL from C#, but it's going
to be a lot more work that way. But this is only for non-visual middle
tier objects.

Eric
 
Claus,

So you might want to take a look of this as well:
http://support.microsoft.com/kb/815780/

chanmm

Claus said:
Dear Radhakrishna ,

That is exactly what I am after :-) I got this code working (see
buttom):

But I would like to create a new Form1, and design with all necessary
components and code.

What are the tasks to compile multible sourcefiles (class1.cs and
form1.cs)
and strongname these, to be able to call from un-managed code?

* For startes: how do I compile Class1.cs AND Form1.cs into TestDLL.dll
from
the command line?


Thank you for your help

/Claus


using System;
using System.Reflection;
using System.Runtime.InteropServices;
using System.Windows.Forms;
using System.ComponentModel;
using System.Text;

namespace TestDLL
{
public interface MyInterface
{
void myMethod1();
void myMethod2(string msg);
void myShowForm();
}

[ClassInterface(ClassInterfaceType.None)]
public class MyClass : MyInterface
{
public MyClass()
{
}

public void myMethod1()
{
MessageBox.Show("Hello World... Calling from C#");
}

public void myMethod2(string msg)
{
MessageBox.Show(msg);
}

public void myShowForm()
{
Form myForm = new Form();
myForm.Show();
}
}
}







"Radhakrishna Banavalikar"
Click to expand...
 
Chanmm,

Thank you for the link. I'll give it a look :-)

/Claus

chanmm said:
Claus,

So you might want to take a look of this as well:
http://support.microsoft.com/kb/815780/

chanmm

Claus said:
Dear Radhakrishna ,

That is exactly what I am after :-) I got this code working (see
buttom):

But I would like to create a new Form1, and design with all necessary
components and code.

What are the tasks to compile multible sourcefiles (class1.cs and
form1.cs)
and strongname these, to be able to call from un-managed code?

* For startes: how do I compile Class1.cs AND Form1.cs into TestDLL.dll
from
the command line?


Thank you for your help

/Claus


using System;
using System.Reflection;
using System.Runtime.InteropServices;
using System.Windows.Forms;
using System.ComponentModel;
using System.Text;

namespace TestDLL
{
public interface MyInterface
{
void myMethod1();
void myMethod2(string msg);
void myShowForm();
}

[ClassInterface(ClassInterfaceType.None)]
public class MyClass : MyInterface
{
public MyClass()
{
}

public void myMethod1()
{
MessageBox.Show("Hello World... Calling from C#");
}

public void myMethod2(string msg)
{
MessageBox.Show(msg);
}

public void myShowForm()
{
Form myForm = new Form();
myForm.Show();
}
}
}







"Radhakrishna Banavalikar"
Hi Mathieu,

You can write a function inside the DLL that creates a new Form object
and
then calls:

Objectname.Show();

Expose this function as a public function. You can add additional parameters
that you want to pass in the function definition and by returning a
collection type from the return clause you can receive strings et al.

Seek me if you want more help.
--
Radhakrishna Banavalikar
Vasant-Vihar, Thane, INDIA.


:

Claus a écrit :
I am new to C#, .NET and Visual Studio but I have been coding professionally
for more than 10 years, so I am not a complete newbe :-)

At my work we are now in the process of switching from Borland
Click to expand...
Delphi
to
Visual Studio and C#.
We have a lot of applications that we do not have time to recode to .NET, so
we are planning to do all "new" developments in C#.
And this is where my question pop up:

I need to create a new Database Search form for one of our apps. and
I would
like to do this in C#, so that later developments in .Net can reuse this.

How can I create a DLL that can open a WinForm and return a string
(as soon
as I got this in place, I can start doing real stuff :-))
Another Win32 (un-managed) appl. should use this DLL.

Since this is my first C# project, I need information about all the steps
necessary to do this.



I hope you are able to provide me with guidelines and if possible
some
samples.

Hi,

Basically, I think you cannot create DLLs in .NET in the usual sense.
What you create are called Assemblies (that are confusely named *.dll).
But you can use the libraries you create via COM (cf.
ComVisibleAttribute), which I hope can solve your problem here.

Mathieu
Click to expand...
Click to expand...
Click to expand...
 
Eric,

The reason I would like to call the WinForms from Delphi is just to prepare
ourselfes for C#.
This way I "believe" (read: I hope) I can avoid coding the same dialog again
when the shift to C# is complete.
Then I can just keep using the same dialog...

Thank you for your thoughts. I will read them through again and investigate
your recommendations


Best

/Claus
 
Claus said:
The reason I would like to call the WinForms from Delphi is just to prepare
ourselfes for C#.
This way I "believe" (read: I hope) I can avoid coding the same dialog again
when the shift to C# is complete.
Then I can just keep using the same dialog...
Click to expand...

I don't think you can do this easily. The pain would exceed the gain.

C# is a lot like Delphi when it comes to Windows Forms, so it's not
terribly difficult to re-do your GUI apps. After all, it still comes
down to the basic Windows controls that haven't changed much over the
last 5 years (or more). The VCL wrappers are a little different that
the C# wrappers, but Intellisense is a big help in VS.

The biggest difference on the GUI side is the databinding control issue
- Delphi makes it terribly easy to wire up visual controls to a live
datasource. This model is entirely different in C# because ADO.NET only
uses a disconnected model. You have to learn how to do databinding all
over again, and it's more complex than you might think. But it's also
more flexible in the long run. If you are a big user of Delphi
TDBGrids, you should spend a few days (or weeks) with the .NET grids
and ADO.NET to ensure that you understand them well before going too
far. I had to do a certain amount of re-work in the early days of my
conversion to C# becuase I didn't have a clear understanding of the
model going into it.

If you have a budget for it, and you have a lot of Delphi GUI apps to
port to C#, it might be a good idea to hire a consultant who's an
expert on Windows Forms. He can save you a lot of trouble and
heartache, and you may only need him for a couple months for training
purposes. With all the buzz about ASP.NET it can be difficult to find
an expert on Windows Forms, and it can be frustrating for you if you
don't have someone who can SHOW you how it's done in .NET.

Once you get your mind around the OOP classes it's actually very
flexible. And in 2.0 you can bind controls to data classes, and that's
pretty cool (something Delphi could never do).

Another option is to refactor your code so there's not much actual
processing in any of the GUI elements. If you move meaty processing to
middle tier COM DLLs, those can be re-used by C# pretty easily, without
a need to re-code them.

Our strategy is to port apps from Delphi to C# if a "significant"
amount of work is needed on a Delphi app. But if the Delphi app only
needs a minor bug fix, we just leave it in Delphi. Almost all new apps
are being done in C# unless it has to interop with Delphi components in
an advanced way.

Eric
 
Back
Top