Essentially everything you need to implement plug-ins in your application is some way to dynamically instantiate classes at runtime. As long as they all implement the same interface, you just use it to access its properties and methods.

In COM world this was achieved by calling the CreateObject function. In the managed world you should use AppDomain.CreateInstanceAndUnwrap as demonstrated by the following example:

IBind pluginInstance = (IBind)AppDomain.CurrentDomain.CreateInstanceAndUnwrap("MCPP", "DamirsCorner.Samples.LateBinding.MCPP");

Everything you need to know at runtime is the full class name (including the namespace) and the containing assembly. To get those you can either require their previous registration within the application or you can dynamically discover them by loading assemblies from a predefined location (Assembly.Load or Assembly.LoadFrom) and enumerating their classes (Assembly.GetTypes) whichever suits you situation best.

Either as a user or as a developer you have certainly noticed that sometimes the application just flashes in the taskbar instead of actually coming to the foreground when the SetForegroundWindow function is called. What you might not know is why and when this happens.

As far as the why goes the Application Compatibility Toolkit’s Compatibility Administrator puts it very nicely in the GiveupForeground compatibility fix description: In Windows XP the foreground semantics have been changed to stop foreground focus stealing by one application if another application is active.

Further investigation reveals that this is related to the ForegroundLockTimeout value. It defines how much time must pass since the last user input to allow another process to force its window into the foreground. Before that time such a window only flashes in the task bar. The default value is 200000 milliseconds. The setting is stored in the registry:

HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout

The value can be programmatically changed by calling the SystemParametersInfo function as follows:

SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, 0, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE);

The downside is that the call only succeeds when the calling thread has permission to change the foreground window which usually isn’t the case.

To make the long story short: you should never depend on being able to bring your application window to the foreground and this will certainly only get more restrictive in the future. If the flashing in the taskbar is not enough, you should consider using tray balloon pop-ups as the alternative way of notifying the user.

By default the Windows XP Welcome screen shows the users created through the control panel applet. Administrator is shown only if it is the only account with administrative privileges. You can change all that by setting up the correct values in the registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList

To change the default behavior for a user create a DWORD value with its name identical to the account name and set its value to 1 to show it or to 0 to hide it.

I really need to write down this information here so that I won’t be googling for it every time a friend or a coworker asks me about it. The default port number 3389 for RDP (Remote Desktop and Terminal Services) can be changed through the following registry value:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber

Due to tightened default security in Windows 2003 the file shares cannot be accessed without logon in a domainless environment even if both shares and folders are set up to allow access to Everyone.

A bit of googling returns many different suggestions for solving the problem, none of which really seems to work for sure. I’m just adding my two cents to this confusion, hoping that this posting will help me the next I’ll be solving the same problem.

It’s all about configuring the Security options in Local Security policy. The logical path of enabling the Network Access: Let Everyone permissions apply to anonymous users policy and disabling the Network access: Restrict anonymous access to Named Pipes and Shares policy didn’t help. On the other hand enabling the Accounts: Guest account status policy and setting the Network access: Sharing and security model for local accounts policy to Guest only - local users authenticate as Guest did the trick. Don't forget to call gpupdate after changing the policy to enforce it immediately.

I’m not asserting that this is THE solution but it worked for me. However, you should be aware of the implications of enabling the guest account before doing it to solve your immediate problem.

A few additional words on the last mentioned policy change: It proves useful when the file server and the client have the same usernames defined but the passwords don’t match because it forces the client to login as guest. By default the client tries to login to the server with wrong password which once again causes the login prompt to appear. It is useful to keep the default setting when the password is the same because the auto login allows for granularity in security settings if more than equal permissions for everyone are needed.