• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 400
  • Last Modified:

unload a dll assembly

hi all,

I have a problem when loading the same assembly twice (it's an assembly containing a form). when loading I'm sending some variables to the new assemblyform to make it ready for my needs. when I close the assemblyform and want to open it again, the refresh event sent to this assembly won't work anymore. do I need to unload the assembly and load it again? how do I do it?

thanks in advance

d.
0
ingprokop
Asked:
ingprokop
  • 8
  • 7
1 Solution
 
abelCommented:
I'd be very interested to see how you execute some code during the assembly load, as unless you use the LoadEvent from the domain manager, you cannot do that without having a mixed assembly and compiling it in C++ and even then, it is very tricky to get right...

Also, an assembly, once loaded, cannot be unloaded.

But I think you mean something else. Correct me if I am wrong, but are you trying to load a second instance of your form after closing the original instance? If not, can you elaborate a bit on your requirement?
0
 
ingprokopAuthor Commented:
this is code I'm using to load the assembly and create an instance of it's form

Assembly assembly = Assembly.LoadFile(Directory + "assemblyform.dll");

Form form = (Form)assembly.CreateInstance(className);

then I'm sending an event with some variables to update the controls on the assembyform. works only once.

when I need to open the form again, I use the same procedure... open the assembly, create an instance of the form etc.
0
 
abelCommented:
Loading an assembly twice does not have the effect of loading the assembly twice. You will only need to load the assembly once. Once loaded, it is loaded and it stays loaded, even if the Assembly object goes out of scope.

What you meant with "when loading an assembly", you actually meant "when instantiating the form". How does the code look that sends the refresh event and how does the code look that does the redrawing upon receiving the event? Are you sure you are sending it to the correct form?

Is it a possible workaround for you to hide the form instead of to close it? Can the refresh event be fired multiple times to the same form? In that case, hiding and showing is probably an easier way to achieve the same goal and much more efficient too.

-- Abel --

PS: if you are hard-coding the assembly name in your code, you can also create a reference to the assembly through References, which makes all the objects from the assembly directly accessible and you do not need to use this cumbersome and slow late binding anymore.
0
Never miss a deadline with monday.com

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

 
ingprokopAuthor Commented:
I can't hide it, it needs to be closed. imagine a button which loads a form. the user specifies a path and the button1.clicked opens the form and closed the old one opened. everytime the button is clicked I'm loading an assembly the way I wrote before and instantiating the form it contains.

I'm using an interface library to send the events to and from the form. that definitely works. but just once.


Assembly assembly = Assembly.LoadFile(Directory + "assemblyform.dll");

Form form = (Form)assembly.CreateInstance(className);

Refresh += new EventHandler(((Interfaces.Data)form).Refresh);

                    if (Refresh != null)
                    {
                        Refresh(Sender, e); //do send variables
                    }




0
 
abelCommented:
The code bits on themselves don't give enough context to understand your question. I looked up some of your older questions and found that daveamour has helped you extensively. Do you know of the E-E feature "Ask Related Question", it will give the commenters of your original question an extra email and it will show on top of your new question so that other experts understand where you are coming from.

I downloaded the excellent example from daveamour, which worked almost instantly. Now it is also clear why you use terms like "assemblyform" even though technically there is no such thing as an assembly form vs. a normal form: they are all just forms (perhaps with extra interfaces or methods).

Back to your question: can you update the example from daveamour in such a (minimalistic) way that it examplifies your problem? You don't seem to do anything wrong (apart from using Assembly.LoadFile more often then you need to, but that's not interfering with the correct workings) but without seeing the larger picture or being able to mimic your situation I'm afraid I cannot do much...

If you upload, rename the zip file to *.txt or something, otherwise, EE refuses the upload.
0
 
ingprokopAuthor Commented:
I think I got the problem, not the solution yet.

I'm sending an event to the imported form to close the form. when the form is closed I'm not able to access it anymore even if reopened.

open the example by daveamour. open the form and Create Assembly Form by clicking the button. right then, close it. do this 3 times. after then, Create Assembly Form again and Raise Event by clicking the other button. you'll see that for each opened form before raising the event you'll get a message box. if you build the solution again and right after Creating Assembly Form you Raise the Event, everything works fine... until you close the form again.

if there are more than one sort of the form... you can imagine.
0
 
ingprokopAuthor Commented:
I made everything like daveamour suggested and everything works perfect, just this issue. somehow when Raising the Event, like in this example, sending the Event can't find the right form to send it to. with the Messagebox you can see it all, I don't use any Messageboxes so I couldn't see the issue properly
0
 
ingprokopAuthor Commented:
the easiest way I can do it right now is to show and hide the form as you suggested before. will try it and will come back soon.
0
 
abelCommented:
small Q: why using events? You can also use simple method calls and an interface that is implemented by all forms, right? Will likely be much easier and prevents the binding to the events issues.
0
 
ingprokopAuthor Commented:
with hide and show everything works great. thanks a lot.

can you post me an example how to "bind" the methods?
0
 
abelCommented:
See the form AssemblyForm. It inherits from IPluginAble. You can add any method to IPluginAble and that method must then be implemented by AssemblyForm. From your MainForm, you can simply cast to IPluginAble. Of course, this means you need a shared library CommonInterfaces that you can use, but you already have that.

// get the form
Form form = (Form)assembly.CreateInstance(className);
 
// get the interface
IPluginAble pluginAble = (PluginAble) form;
 
// use the interface
pluginAble.RefreshForm()
 
 
// interface now contains events, but you can add any method:
public interface IPluginAble
{
    event EventHandler ButtonClicked;
    event EventHandler TextHasChanged;
 
    void SomeMethod(object sender, EventArgs e);
    void RefreshForm();    // added a method to interface
}

Open in new window

0
 
ingprokopAuthor Commented:
Great, thanks a lot. so it's the same as in daveamour's example... thank you guys, that really helped me...
0
 
abelCommented:
No, it's not the same. I took his example to make it easier for you to grasp. I added a method. You can forget about the events, unless you have a special reason to use events. I only left them in so you had a reference to where my idea came from and where you should put your new logic and new approach.

After you're done, the interface should look like this:

public interface IPluginAble
{
    void RefreshForm();    // added a method to interface
}

Open in new window

0
 
ingprokopAuthor Commented:
I meant the principe is the same
0
 
abelCommented:
aha, ok, sorry ;-)
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 8
  • 7
Tackle projects and never again get stuck behind a technical roadblock.
Join Now