get an error when convert window application form into dll

Question

0.00/5 (No votes)

See more:

Hi, I have 6 window applications form need to convert into dll(s) since i need to put that 6 applications into another big window application form. i tried to convert 1 of them using this instruction( How to convert a windows form to dll[^] ), but getting so much errors.

e.g:
Handles clause requires a WithEvents variable defined in the containing type or one of its base types.
Event 'Load' cannot be found.
'Visible' is not a member of 'GillWind1.GillWind1'.
'TextBox1' is not a member of 'GillWind1.GillWind1'.
'End' statement cannot be used in class library projects.
'ComboBox1' is not declared. It may be inaccessible due to its protection level.

Please help.

Posted 11-Dec-13 16:05pm

nca8503

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2013-12-11T17:42:00

Do something very different. Don't move any files or add anything. Do the following:

If you want to preserve your existing application project(s) and solution (always a good idea), make a full copy of it to a different location not changing anything. Make sure it compiles and works.
Go to project Properties, first tab, change "Output Type" from "Windows Application" to "Class Library". This already will give you a DLL. (Remember, in .NET, the difference between "EXE" and "DLL" is very minor.)
You got a class library assembly. For this assembly, entry point (static method Main) is totally redundant. Remove it, and remove all code which is needed only for the purpose or executing this part of code. Don't remove your form(s) and code related to their functionality.
Review your code for access modifiers. Remember that the purpose of your assembly is to be used in other assemblies, and other assemblies, to access the methods and members with need public and protected access modifiers. (I don't mention reflection here; it would access anything regardless of access modifiers. Let's talk about the access through referencing assemblies.) Don't give more access than it is really required.
Now you need to test your library code with some application. Create a brand new Windows Forms application. If you want to use some form from your library as the main form of this test application, remove its main form and the code depending on it.
Add the reference to the library to your test project. It's the best to have them in the same solution and use reference by project (the tab "Projects" in the "Add Reference" window). For the main form of new application, use one of the forms of your library (if possible; if this is not the purpose, create forms on some events, like button or menu item clicks on existing form). Test all you need, fix the problems.
Finally refactor your library project with your test project, keeping in mind its purpose as the library. It may need more adequate names, structure, preparations for adding abstraction. This is a very informal item; you will need to use your own common sense and understanding the the project purpose.
Use your library in your real application project(s), in the same solution. One of the ways to do it is to re-work your test application to be used as the working application prototype.
PROFIT!

This way is much, much smoother than the one you have tried. It completely eliminates the problem you have described, because you never do any "dangerous" steps and do one step at a time.

Now, a word of the difference between "EXE" and "DLL". The real difference is just the name and the entry point in "EXE". You can really reference "EXE" in exact same was as it would be a library. It perfectly works and has some real-life uses. From the other hand, you can create a special host which will load and use either DLLs or EXEs as applications; and example of such architecture would be some plug-in architectures.

—SA

Ron Beyer · Accepted Answer · 2013-12-11T16:09:00

Solution 1

You should avoid, at all costs, naming the library the same as any type it contains. In this case, you named the library GillWind1 while it seems to contain a form called GillWind1. This causes problems trying to resolve types.

Posted 11-Dec-13 16:09pm

Ron Beyer

Comments

nca8503 11-Dec-13 22:18pm

I have changed the library to GillWind3 but still get same error.
'Visible' is not a member of 'GillWind3.GillWind1'.

Ron Beyer 11-Dec-13 22:47pm

Can you post the code for the line that the error is on?

Ron Beyer 11-Dec-13 22:48pm

Also, when you created the DLL project, did you create a Custom Control library, or just a DLL project?

nca8503 11-Dec-13 22:55pm

I create Class Library. for custom,that you mean WPF Custom Control Library?

Me.Visible = True
Application.DoEvents()

Ron Beyer 11-Dec-13 22:58pm

No, you need to create a WinForms control library (Usercontrol or Custom Control) so that the proper references are added. Otherwise look at the original WinForms project and make sure the DLL project includes the same references.

nca8503 11-Dec-13 23:26pm

ok, i have changed to create project windows form control library.now, get 2 errors only.

'End' statement cannot be used in class library projects.
the code:

If (MsgR = MsgBoxResult.Yes) Then End

Ron Beyer 11-Dec-13 23:31pm

Yes, that's true, you could possibly use Environment.Exit() but its not recommended to attempt to close an application from a library. Your code should signal that it needs to be closed or raise an exception.

Sergey Alexandrovich Kryukov 11-Dec-13 23:02pm

Ron, what do you mean by "library name"? If this is the name of the file of the main executable module of any of the assemblies, it does not matter anything at all. The namespaces and type names are totally unrelated to this name. If you mean any other name related to it, your "avoid at all costs" statement looks like an exaggeration. All name conflicts are pretty easy to resolve.
—SA

Ron Beyer 11-Dec-13 23:06pm

Yes, its not too difficult to resolve, but if you are just copy/pasting types from one project to another (such as the case here), you will have to fully qualify conflicting names. For example, if you have a project names MyLib and you have a class inside it called MyThing, then you move MyThing into a namespace called MyThing, anything that refers to MyThing will now have to be called MyThing.MyThing in order to resolve.

This isn't as much of a problem (other than just plain confusing) when creating a new project, but when migrating a project of one type to another then it will throw a lot of errors until the type names are corrected. This is one of those things that I learned the hard way on a huge project.

Sergey Alexandrovich Kryukov 11-Dec-13 23:21pm

Again, "project name" is also unrelated to both namespaces and executable module file name. Both file name and default namespace can be chosen independently in the project options. Moreover, this default namespace does not affect anything at all, in case you just move files around, because if does not change namespace. One can choose any namespaces in code, totally ignoring default namespace. This default namespace only affects auto-generated code.

But you have some point here, which is not absolutely important, but the implications are good to understand. You should have said: "avoid using namespace names identical to any type names", then it would be a useful advice. I'm also not sure that this advice will solve the problem. The names are already given, OP just needs to work accurately and eventually rename things more reasonably, using the refactorization engine.

Besides... I have an idea.

—SA

Ron Beyer 11-Dec-13 23:32pm

True, I typically copy/paste the meat of my code files when I migrate code to new libraries, so I change namespaces. I overlooked that the namespace would be copied over when copying the entire file.

Sergey Alexandrovich Kryukov 11-Dec-13 23:44pm

Okay, I finally realize what the problem is. This is wrong (workable, but ugly and not smooth enough) migration procedure OriginalGriff advised. I explained much smoother method which eliminates "dangerous" steps. Please see Solution 2.
—SA