|
Quote: That one had occured but it meant that a user of the class would need to know that the overload without a method would give ByLuminosity, which was the bit that felt unintuitive.
The issue of being intuitive is very subjective. I see the intuitive part being to use the "ToGreyScale" method and even that may require some explanation. At some point a programmer has to demonstrate some competence and look at the provided documentation. This is the reason that I showed the visual studio intellisense support using xml comments in the code I posted (see: Documenting Your Code With XML Comments). Providing this documentation is your responsibility as the developer and you should not be relying on something being intuitive as a substitute for proper documentation. Paste the extension method code I provided into a project and observe the intellisence pop-ups when you try to use the defined methods.
Quote: BTW, thanks for the piece, I assume that's how extension methods work?
Assume nothing  when coding. Use your friendly search engine and research it yourself. I have found that this general query works well in the major search engines:
msdn TopicYouWant -social"
The reason for the "-social" is to try to eliminate results from the msdn help forums and to focus on the documentation pages.
So much for my preaching for the day, have a good weekend. 
|
|
|
|
|
Thank you. My code is XML commented I just left it out of the simplified examples here. For the extension methods I'm not sure why I left the question in, I had searched Google, guess I was just looking for confirmation - probably not necessary.
On the structure, I agree but something feels clunky, nevermind.
Have a nice weekend
|
|
|
|
|
I have an DLL assembly that is used by many other apps. This assembly is likely to change as new requirements are discovered.
Now, let's say the referencing apps are all running, I change the code in the dll for a new app, and then start the new app.
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?
If so, is there a way to force the new app to use the copy of the dll that it was linked to instead of using what's already in memory?
".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
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
