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?