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.
I am getting following error when I am trying to assign a null value or nuthing value to a variable of type Nullable(Of Decimal).
But for that variable I want to assign a decimal value or null value. The same kind of problem I faced with Nullable (of DateTime) too. It cant take a nothing assigned to it. If it cant take that value then why is it nullable(of Decimal) or Nullable (of DateTime) and System.Nullable(Of Integer) is also not taking null values (means nothing value in VB.Net).
Please help me in resolving this issue.
thanks in advance.
Below is my code: I tried by just putting variable=nothing also but didnt work.
If savRequestData.PropRequestWage IsNot Nothing Then
wagesegment = New List(Of ReqWage)
For Each temp In savRequestData.PropRequestWage
Dim wage As New ReqWage
wage.DailyWage = IIf(Not String.IsNullOrEmpty(temp.DailyWage), IIf(Decimal.TryParse(temp.DailyWage, tempDecimal), tempDecimal, CType(Nothing, System.Nullable(Of Decimal))), CType(Nothing, System.Nullable(Of Decimal)))
wage.RequestId = request_Id
wage.WorkDate = temp.WorkDate
wage.WorkHours = IIf(Not String.IsNullOrEmpty(temp.WorkHours), IIf(Decimal.TryParse(temp.WorkHours, tempDecimal), tempDecimal, CType(Nothing, System.Nullable(Of Decimal))), CType(Nothing, System.Nullable(Of Decimal)))
requestedamount += IIf(temp.DailyWage IsNot Nothing, temp.DailyWage, 0)
OK. Thanks Dave. That clears it up. The text box values are not of consequence but if they are null it is a problem. Trying to add them to a listbox is rejecting null strings. Position in the list box is critical for each item added so a place holder needs to be added.
We have a new requirement that a daily file transfer of client data be encrypted with PGP. I would rather not rely on a blackbox solution, as I want to make sure that the file is not being secretly sent off somewhere.
Can anyone help me find .Net source code to do PGP encryption/decryption? C# or VB.net are both fine, I can work with either. I do not need -- and frankly, would rather avoid -- all of the other bells and whistles that have become common with PGP packages. All I need is file encryption and decryption using an public/private key that follows the PGP protocols.
Last Visit: 25-Nov-20 19:00 Last Update: 25-Nov-20 19:00