Cool!

Wonderful, thanks a lot to both of you, that is exactly what I needed for this project, but will play with your other suggestion like creating a test menu with several user loging for testing.

Here is my final code in AppMain.vb, for now

Edhy Rijo

The one I was talking about is a Compilation constant. In code you'd use:







This is setup under the main project's properties, on the compile tab, click advanced compile settins. There is a checkbox to "Define DEBUG constant". Typically, the default debug build will define this constant for you (were as a release build won't define the constant).

Thanks you Dusting, Greg.

One more thing, how do you test for debug mode?

Edhy Rijo

Yep, that would be where to put it. Test on your developer criteria (debug mode, registry key, encrypted xml, whatever you decide) and if that is valid, do the automatic login in place of showing the login form.

Heck, one way to do without plumbing holes into your app is to add the ability to provide the username and password combination through command line switches. Then just setup your shortcut to plug those in for you .

Hi Greg,

As always your input is very much appreciated.  In my case I just need to have the initial user logged, so I can test some functionality and then be able to press F11  (Session Lock) to login with another user to keep testing.

I would use your #1 option, but where to put the code?, should I disable the Login form in the AppMain.vb?

Edhy Rijo

Good ideas from Greg on this. Checking on Debug mode is our preferred way to do this type of thing (debug builds can still be distributed to testers, though this obviously isn't ideal.)

One more for keeping it developer only is to check on a "Developer" registry entry. The entry can contain any kind of value that you want (i.e. an encrypted hash), just check for that key with that value before allowing the quick login. For added security you could even have the value "roll" weekly, monthly, etc. so that if the cat ever got out of the bag regarding the key and value, it would only be valid for a short time period.

Funny you should ask this, I've been thinking about how to do this myself. Here's what I've come up with so far:



1. You can programatically login using Login.SetLoggedInUser(user, password, domain). This sets the SecurityBasics.CurrentUser. So, that's not hard.



2. You could have some menu/button/thing-a-ma-jig that would just call some preset users.



3. You also need to be able to make danged sure this doesn't deploy were you don't want it to. You could use a Compilation Constant, like DEBUG to include/exclude the code. However, that only works if the developer is the only one using this feature. I have a coworker who is my first tier tester, and it'd be nice if she could use it too...so I'm still thinking about the best way to do that.



I'm thinking about providing a little app that would create an encrypted XML file with the possible users, have that file get loaded so the user can just choose who to login as. Then this would only be available based on user/deployment type (I'm using clickonce, so I can discern deployment types (alpha, beta, prod) that way). Of course the uses would only be valid in a test environment.



Anyway, those are my thoughts on how to get this done. Hope that helps!

Is there a way to pre-fill the UserName and Password while testing the RBS features instead of typing that info all the time?

Edhy Rijo