|
The running application (or new application using currently cached DLL) doesn't know about changes to the DLL itself in most cases, so you'd have to write some kind of polling thing, or event response to the Windows file changed event, and pick up the new DLL and link it in "manually" like this...
Assembly assembly = Assembly.LoadFrom("MyLibrary.dll");
Type type = assembly.GetType("MyType");
object instanceOfMyType = Activator.CreateInstance(type);
This is frustrating for sure, when you have lots of apps using the same DLLs - I've had this issue with multiple web sites before, and it took us a long time to understand what was happening. You would think that copying over the old DLL would cause a system-wide "this DLL is no longer up to date" kind of event, but apparently not.
|
|
|
|
|
I tried using strong naming, but that had no effect.
WTF good is code re-use if I can't actually re-use the freakin code in compiled form?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
Yeah it's not ideal. Sometimes you have to re-start the server. I think they opted for making it harder to use the wrong assembly instead of easier to manipulate which ones are used.
|
|
|
|
|
John Simmons / outlaw programmer wrote: ...by many other apps.
What do you mean by "app"? Or more specifically how many process spaces are you running into which these apps appear?
An executable/service has a load dynamic that, excluding GAC, will load based on several factors but the primary one is the current working directory of the primary executable. A new process space will load a new copy of the dll that it found doing an assembly search. It doesn't have anything to do with what other processes have loaded into memory.
Now if you are messing with AppDomains and changing the loading semantics then that alters how it searches and that would alter where it looked. The process would still load a new copy though.
John Simmons / outlaw programmer wrote: What I'm seeing is that the new app uses the version of the assembly that's
already in memory. Is that an accurate statement?
Not in general, but as noted it depends on what you mean by "app". The process (AppDomain) loads the dll into memory. It won't load it again, but every process gets one (I can't remember if there is AppDomain chaining or not.)
|
|
|
|
|
Sure that's what should happen, but I've seen a DLL basically get "locked" on the whole machine, and even though we replaced the DLL itself, the old behavior continued until we shut down the web server. This was on a web site where several sites used the same ORM assembly, and it appeared that IIS was loading one copy of the DLL for everybody, and it refused to let go of that even when the underlying file was DELETED. We had different app pools for each site, so it was really unexpected. I would have thought it was impossible, actually.
Pretty sure that's what he's talking about happening, and I agree it shouldn't happen, particularly when he said he starts a new copy of the app. It completely baffled me and a few guys in India - we couldn't figure out what was going on, and after that night(!) it became standard procedure to re-start the web server after rebuilding the ORM assemblies.
|
|
|
|
|
Jasmine2501 wrote: and it appeared that IIS was loading one copy of the DLL for everybody, and it
refused to let go of that even when the underlying file was DELETED
IIS is a process. It (presumably) uses AppDomains but that goes back to whether chaining is involved.
And per the docs chaining can happen at least with the default AppDomain.
And of course if chaining is involved then deleting the dll would have no impact - if .Net finds the assembly in memory (within the Process/AppDomain context) then it doesn't load it again.
|
|
|
|
|
If you want to keep both the new and the old dlls, you can use something called a Publisher Policy.
This would allow you to use the new dll. If you want to use the old one just set the publisher policy setting off.
More here[^].
|
|
|
|
|
Hi,
I am looking for an event to hook into that occurss after aform has been created, but, before the form is displayed. In MFC I would use OnInitDlg().
My Main Window is essentially aSplash Screen. I want to display a LogIn Screen op top of that.
If I do that in the constructor, the login box isnaturally displayed first, followed by the splash screen. The Splash Screen does not create events to hook into.
Furthermore, How do I call the Base Class version in a handler I override. Below is how I woulddo thisin CPP. but this code will not compile in C#.
namespace SgCntr
{
public partial class MainWnd : Form
{
protected override void OnXXX(EventArgs e)
{
Form::OnXXX(e);
LogOn logon=new LogOn();
DialogResult dlgres=logon.ShowDialog(this);
}
}
}
Bram van Kampen
|
|
|
|
|
|
Hi,
Thanks.
The MSDN Ref you point me to is quite sparse, and does not realy cover the topic. (it covers events sent by a button click. It purports to document the Load event, but is silent about this in it's explanations)(not your fault, I blame Steve Balmer). I'd say a lot is missing. primarily the 'HowTo' hook into a 'Load'event. To prove the point, I did as the sample specified, and pasted the code in to a form, according to instructions. Unsurprisingly, nothing happened when the button was clicked. In MFC terms, the message map entry is missing, in SDK terms, the message is not intercepted in the WndProc, I suppose, in .NET terms, the handler delegate has in the example, not registered with the event.
Kind Regards,
Bram van Kampen
|
|
|
|
|
Unfortunately MSDN is a travesty of reorganisation. It used to be very easy to locate stuff without leaving the site. Nowadays, you have to rely on an external search site to find stuff on the microsoft site.
Luckily I don't have such a problem, as I still have early versions of MSDN on DVD, so I'll see what I can dig up on this issue.
|
|
|
|
|
Thanks, much appreciated. Look forward to hearing from you.
Bram van Kampen
|
|
|
|
|
In many ways, although the syntax looks similar there are fundamental differences between C# and C++, so you will find the behaviour quite strange at times. Look at the various events available on the System.Windows.Forms.Form class[^]. I don't know the details of your splash screen but if it's based on a Form then it should have all the same events.
Use the best guess
|
|
|
|
|
Well Richard,
Thanks for your reply, and, good to hear from you again. The differences between C++ and C# I'm acutely aware of. It brings me new surprises every day. Strange behaviour I have seen indeed. The differences between MFC and .NET are even bigger. Whereas in mho MFC acted as a convenient thin (sometimes a very thick) Object Oriented wrapper around Windows SDK, NET is an entirely new departure. Our reason for changing to .NET is to become OS independent. Our software runs without any hitches or security issues on very many XP terminals, (none of which is connected to the internet). There are too many issues for it to run properly under Vista and above. The main flee in the ointment is the paranoid security system in Vista+, which is entirely supurfluous to our requirements.
The original incarnation was written for Win3.1, (1 elderly customer is still using this on two terminals) in the then revolutionary new MFC. MFC at the time binned about a 100 books by Petzhold. Porting to Win98 was painless, actually it simplified matters greatly. No more worries about far, near, and burgomasters. (one could no longer look at another process though! (ouch!) That was a major issue at the time).
The performance requirement for the product is identical under MFC or .NET . Paint a screen, Let the user fill in data, wait for a button click, and respond to the click by doing things like accessing a database, or, painting another screen. As the whole suite of programs is Dialog based, there are very few programming 'High-Stands', the most involved part being the provision of 'Progress Dialogs' for lengthy Database enquiries. In MFC and SDK we monitor messages, in .NET we use events. Different Mechanics, but similar overal end results.
As for the Database, Version 1.XX (Win 3.1+) and Version 2.XX( Win95 to Win XP) used a proprietory DB system, with much of the DB Code dealing with atomicity of transactions, ending up in the middle of the Dlg procedures, i.e. the Presentation code. We intent to use SQL for V3.00 (Win7 and after)
Thanks for the Link. It gave a method listing which included an 'OnLoad' method. The help system on my version of VS2012 sent me to a similar help page which did not contain any event handlers. This latter fact added to my confusion. We had a 'Load' event, but not an 'OnLoad' event handler. The so called 'Intellisense' (I rather have a decent paper manual)was also quiet on 'OnLoad'
Thanks again,
Kind Regards,
Bram van Kampen
|
|
|
|
|
Thanks for your kind words, Bram. I have found that the online MSDN documentation is usually the best source of information. It can be a bit daunting at first, and occasionally leads you down blind alleys, but overall it is still high quality.
Good luck with your project(s).
Use the best guess
|
|
|
|
|
Hi Bram,
either use the constructor to do a method call where you do the stuff you need to do, or use the Form.Load Event[^] which occurs before the form is shown the first time (for example, location of the form on the screen can be set there).
Hope I was able to help you!
|
|
|
|
|
does anyone know if i can create a .net application as a service which would still be started even if the user restart and doesn't log in?
|
|
|
|
|
That's kind of the definition of a Windows Service application. They run when Windows starts, not when a user logs in.
If you were thinking that you were going to write a service application that puts up a user interface the user can see, forget it. That's not allowed for security reasons. If you wanted to do something like that, you'd be writing TWO applications. One would be the service that is constantly running and the other would be a normal application that runs when the user logs in and communicates with the service over an IPC method of your choice.
|
|
|
|
|
ah ic, thanks you very much.
i am probably gonna create two application. though i never used an IPC method before.
|
|
|
|
|
neodeaths wrote: i never used an IPC method before.
IPC Stands for "InterProcess Communication". Read this[^]. I would suggest using Named Pipes.
|
|
|
|
|
All services start before login so the service should start even if the user does not login.
|
|
|
|
|
I don't think that it is possible to create such kind of application service, but you can try it your way.
|
|
|
|
|
A windows system service starts as soon as Windows is started - Remember that a service may not be able to access user-specific folders and files when the respective user is not logged in!
- MB
|
|
|
|
|
if i need to save a little bit of application data. what can i use besides database and still be sure that i will have access to it?.
should i use registry? or save the data in an flat file in the program files?
|
|
|
|
|
You can't save anything to program files or below. It's readonly to normaly users.
You can get the path to an appropriate place to put your data from this list[^]. Use Environment.GetFolderPath[^] to get that path, then combine it with your data filename using Path.Combine[^].
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
