Thank you halabella for your answer.
It can be a possibility but in this way I think you lose the behavior of the button (button pressed - button not pressed).
In my particular case I could just use an image because the text I need to write is a symbol of a font type not included in my Windows CE (for this reason I need to put an image in a button) but there would be much difference aesthetically with the other buttons of the form.
...but perhaps I could change the image on the click event... yes, it is a possibility.
My C# solution contains several EXE's and one DLL. All of the EXE's hold references to the DLL because they all depend upon the types implemented by the DLL.
Now, even if I make a trivial change to the DLL that does not alter the public interfaces and methods of its types, Visual Studio rebuilds not only the DLL, but also all of the EXE's that depend upon it.
So my question is: Must I redistribute the rebuilt EXE's as well as the rebuilt DLL, even if my changes to the DLL do not alter any public interfaces or methods?
It seems to defeat the purpose of putting widely used types into a common DLL, if I must rebuild and redeploy any EXE's that use the DLL after making strictly internal changes to the DLL.
Thank you for reading my question.
The difficult we do right away...
...the impossible takes slightly longer.
I got a requirement of applying method level security for the logged in user.
What they just instructed is:
for every method in the code there will be corresponding binary code ..
and for each permission for this method there will be binary code too..
Now when user log in window application it will be checked if this user has permission to execute this method.
I dont have any idea about this..
can anybody provide good links for it or if someone has ever implemented this sort of thing.. Help me out..
You could use the RoleProvider to determine whether or not the user has the appropriate permission to execute a particular method.
I will say, however, that you should be approaching this from the perspective of what the user sees rather than locking off individual methods. In other words, it's better to prevent the user from being able to see a menu option/click it, than it is to let them click it and then tell them that they didn't have the appropriate permission to execute the method.
As you haven't stated what technology you are using, this is as close as I'm going to be able to give you a full answer without overloading you with details for technologies you aren't interested in.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
I used to encrypt and store my applications (Web Forms – Windows Forms) user password in the database.
I usually during the creation of a new user, I get the user password as a plain text and I create a new hash value then I encrypt the concatenation of the password plain text and the hash value. I store both the encrypted password and the hash value in the database.
During the user login authentication process I get the supplied user password as plain text then I retrieve the stored hash and the encrypted password for that user from the database. I repeat the same encryption again which I used during the new user creation operation but with concatenation of the retrieved hash from the database and the supplied plain text password then I compare both the database retrieved encrypted password with new encrypted password. If they are matching the login validation passes otherwise it fails.
I used to use "FormsAuthentication.HashPasswordForStoringInConfigFile" in the namespace "System.Web.Security" to encrypt the passwords for both of my windows Forms and web forms applications. But now with the .Net framework 4.5 the following method:
"HashPasswordForStoringInConfigFile(Password as string, PasswordFormat as string) as string" is obsolete.
Please anyone have any idea what is the new alternative for this method?
does VS put some files in Bin, and other files elsewhere?
Yes. Take a look at the directory structure under your solution directory and you will see the other directories. You can also look through your project properties to see which part of the build uses which directories.
One of these days I'm going to think of a really clever signature.
You could change the output path by simply setting the output path attribute in the project's Build properties.
They could be put elsewhere so long as all the dependent dll's are also available in the same folder.