If the process comes back after killing it, its getting started by another process. Trick is to kill both at the same time. Have you got sysinternals tools on your box?

In my experience, cowboy coders rarely listen and will seldom change their habits - no matter how good the argument: following process takes the 'fun' out of coding and there will be a lot of resistance. The only times they do tend to listen is when (1) disaster strikes and they have to explain to higher-ups why something was/was not done or (2) a more senior party (given rank) moves in and "assists" them in changing their habits. Otherwise, frankly, you're fighting a losing battle. Of course, this doesn't help with your argument - disaster won't just strike after deployment due to security being added last. Reading from your list of processes still to be implemented (e.g. you don't have source control yet; seriously!?) you seem to have other urgencies as well! But for the sake of helping your argument... (1) are there contractual risks if someone should gain access to information withing the system that they're not supposed to see? (i.e. what is your company's liability towards leaks due to inadequate security) (2) is security not something that they feel needs to be beta-tested as well? (3) [also countering their argument] unless you have an "all or nothing" model (I assume your needs may be slightly more complex), adding security after earlier rounds of testing would invalidate earlier tests and you are likely to see instances where undiscovered bugs will prevent the use of parts of the live system. Think about it: modules already tested won't get tested in as much detail again.

Yeh... I once got asked to calculate the weight of the new Airbus as it lands on Heathrow airport (fully loaded), given the atomic weight of copper, alluminium, etc. I got close... very close...

The second certainly looks cleaner; but sometimes you need to do cleanup (dispose objects, free memory, release handles, etc.) before exiting a function / method. If you add code later that needs cleanup, and already coded the second way, you'll have a lot to change... in addition, code that is already out there running stable is more valuable than new code, since you risk introducing bugs by changing from your second example back to the first. So I'd definitely go for the first - good habits breed consistency.

Try this... result = MyString.Replace('[','').Replace(']','')

Should work fine; can you provide the code for this?

Hi Was just wondering if anyone else out there has tried this before... Basic problem is that I need the currently logged in user's name (ie. the username he used to get into his workstation). Anonymous login has to be allowed, but if the user is logged into the domain, I want his name. This is to enable seamless login for users using a web app. Security isn't an issue here (yet...), and the app is internal use only, but I do need the user's (domain) login name. Nothing more. If you know linux; my environment is probably similar to the following: * Domain controller: Linux; OpenLDAP * IIS on Windows 2003 Server * Linux desktops with Firefox (This should provide a parallel if you're more familiar with Linux than Mac - answers to this might get me closer to the goal). But the actual environment: * Domain controller on Mac OS X 10.4 server (running LDAPv3; based on OpenLDAP, I believe) * IIS running on Windows 2003 Server * Mac desktops (OS X worstations) - users working off Firefox and Safari Question is how to get the user's currently logged-in domain username, through a web app. Thanks and regards ehuysamer

DirectoryEntry entry = new DirectoryEntry("LDAP://testdomain/DC=testdomain", "testdomain/" + textUser.Text, textPassword.Text); Object obj = entry.NativeObject; DirectorySearcher search = new DirectorySearcher(entry); search.Filter = "(SAMAccountName=" + textUser.Text + ")"; search.PropertiesToLoad.Add("cn"); SearchResult result = search.FindOne(); if (null == result) { . . . } This only works with AD, by the way: if you find that works with LDAP, please let me know

Thanks - have you perhaps got a link to it?

Are the fonts you use in your app installed on both platforms?

Hi I was wondering if anyone could offer some advice on authenticating a .NET application with LDAP. The code seems to work fine with AD, but fails with LDAP. Also, I have a Java App that can do this just fine, but somehow the solution with .NET eludes me! (extract) DirectoryEntry entry = new DirectoryEntry("LDAP://testdomain/DC=testdomain", "testdomain/testuser", textPassword.Text); Object obj = entry.NativeObject; DirectorySearcher search = new DirectorySearcher(entry); search.Filter = "(SAMAccountName=testuser)"; search.PropertiesToLoad.Add("cn"); SearchResult result = search.FindOne(); if (null == result) { . . . } The test PC runs on a Windows XP box with .NET Framework 1.1, and is bound to whichever server we're testing on at the time. The authentication server is a Mac OS X 10.4 server running LDAPv3 (I believe built on OpenLDAP, and should be similar in every way). Any suggestions? (or anyone with a Linux OpenLDAP domain out there?)

At this point, I wouldn't care if he solves it in 5 secs with a classic "why don't you just..."; BTW: found out from the developer: the info he queried wasn't through .NET, but a Java app. Now things are becoming clearer - can't seem to access LDAP from .NET, only Java, and this even though Windows XP can successfully bind to that domain! X|

You know, on the one hand, a lot of people spent a hang of a lot of time getting some technologies to work together (and done a pretty good job of it, I might add). On the other, it seems that every time you start mixing things, something breaks. Its nobody's fault... its just life! Try this latest one, for example: 1. Developer binds WinXP workstations to LDAPv3 on a Mac <>. 2. Developer uses .NET to query user info from there <>. 3. Developer uses .NET to check an entered password on the LDAP domain. POP - (Slap the developer) - that code was working yesterday, man!! 4. The developer binds the PC to an MS AD domain to prove to you that he didn't break anything. Hey, so it worked [on AD]!! (apologise to the developer). 5. Search the web. 6. Don't panic. 7. Post messages to forums. 8. Don't panic. 9. Panic. 10. Think of assigning it to some unsuspecting new guy on the premise "hey, its easy; I just don't have the time for it right now - Z could do it in half a day: impress me!" Anyone out there like to save an unsuspecting new guy?? (he starts on Monday) (Hell, this is frustrating!!)

Try: catch (SqlException ex). You can get far more from exceptions than that: Put a breakpoint on your MessageBox.Show, then quick-view the exception when the code gets there. You'll get a lot of info from there, including the actual sub-type of the exception that got thrown.

Run character map and have a look at the Wingdings and Symbol fonts (I think the drop-down arrow that you're looking for is in Webdings 3). Enter the corresponding character in the button's text field, and set the appropriate font. You'd probably want give the button an "action" part for executing the default, and a "drop-down" part that shows your pop-up menu; so do this as two separate buttons. Putting these on a panel would also be a good idea. For the actual pop-up bit, set up a context menu to pop up when the user clicks on the drop-down button.

What type of connection is this? Database? File share? Custom protocol? Start by putting all of your communication-related code into a separate class (or at least identifying which classes you use fits this description): should specific exceptions get thrown, you simply reinstantiate or reconfigure the class with different parameters (telling it to use server B). In the case of a database connection, as an example, you would change the connection string. This outlines the structure of a solution, but without more information I can't really help you.

Have a look at the parameters that you are passing. You might try putting quotes around them: " This will not parse as part of the parameters; but be sure to escape any existing "s appropriately. By the way, its extremely bad practice passing passwords as command-line parameters: I'd suggest trying to have the password checked by your web app against the domain, and then just passing the user's name itself to your separate application to do whatever it does with it.

There are a couple of good open source packages available. Start by having a look at those, then decide if such a project is still worth your time. If so, you'll have some good samples to work with. Is this for a company, or a varsity project?

Try adding "ORDER BY [Column]" to your select statement

Hi I was wondering if anyone could offer some advice on authenticating a .NET application with LDAP. The code seems to work fine with AD, but fails with LDAP: (extract) DirectoryEntry entry = new DirectoryEntry("LDAP://testdomain/DC=testdomain", "testdomain/testuser", textPassword.Text); Object obj = entry.NativeObject; DirectorySearcher search = new DirectorySearcher(entry); search.Filter = "(SAMAccountName=testuser)"; search.PropertiesToLoad.Add("cn"); SearchResult result = search.FindOne(); if (null == result) { . . . } The test PC runs on a Windows XP box with .NET Framework 1.1, and is bound to the respective authentication server every time. The authentication server is a Mac OS X 10.4 server running LDAPv3. Any suggestions?