|
That won't work. See Bernard's message below for why it won't.
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
|
I guess it is your application which tries to communicate with the SMTP server.
Hence the application must be able to retireve the clear text password when connecting to the server. Consequently, you cannot hash the password, but you must encrypt it. This also adds the question of how to store the key and the salt value.
Next question is: who configures your application? Is it the "user" who enters his personal SMTP credentials or is it an administrator of the user's company who does so (and applies the same configuration to all installations of the application in the company)? Depending on the answer, you may use a user-specific settings file, a program specific settings file, the *.exe.config file, store data in a database, etc...
Also note that the .exe.config file contains a connectionStrings section, which can be "automatically" encrypted and also used for this purpose.
|
|
|
|
|
Hello Bernhard,
thank you for your reply!
The SMTP credentials are configured by an Administrator and not by the end user, so the SMTP is a global SMTP.
Ok, and in case of an ASP.NET application, this would be the web.config, wouldn´t it be?
To secure the configuration section would this be the appropriate way?
greetings
Nico
|
|
|
|
|
You identified the right section for web.config. I'd suggest to enter the credentials and do the protection during the deployment of the application.
|
|
|
|
|
Use the System.Security.Cryptography.ProtectedData class. It's designed for exactly this task.
|
|
|
|
|
Thank you for your reply, but isn´t this class´ purpose only for encrypting and decrypting data with the dapi mechanism?
|
|
|
|
|
It is. You need to decide yourself, where to store encrypted data - config, settings file, etc.
|
|
|
|
|
Yeah DataProtection api is the way to go
|
|
|
|
|
I'm using Visual Studio 2010.
When I was compiling the execuables that contains 19 different dlls. Each dlls have dependency on other dlls. I just got bumped into a couple of incorrect dlls' date of creation.
For example, one dll 'error.dll' is being depended by half of the dlls which consists of error codes and its translations. some of the dlls has error.dll referenced being pointed to the error/bin/debug and others was pointed to error/bin/release.
When compiling overall solutions, the exe ended up having the wrong version of error.dll. Is there a better way to control the location of reference files... I mean a way to test or ensure that these references are pointed in their right places to ensure that these dlls are pulled correctly?
Thanks... respond back if you have any questions or answers.
~ Ron Boucher
|
|
|
|
|
There are two potential solutions that I normally use.
If you have the DLL that you are depending on in your solution, use a solution reference to refer to it - right click, Add Reference > Solution.
If the reference is to an external DLL, I copy that DLL into a common location (e.g. lib) that exists in the relative path to the solution and all projects use the DLL from that location. The advantage of this is that you can store this in source control, and you can easily sort out versioning issues.
|
|
|
|
|
Hmm I like the 2nd suggestion (external dll). That would sure help out!
|
|
|
|
|
If you have the source for the dll(s) then the Project reference is a much better solution!
|
|
|
|
|
Can you explain why?
Is this the step that you're referring to:
1) right click on "Reference" node
2) Add Reference
3) Click on "Projects" tab
4) Select the dlls to reference
|
|
|
|
|
If the code is a logical part of your solution then having a solution reference means that a full build should never be out of step.
|
|
|
|
|
Yes, first you add the Project for the dll Assemblies to the Solution and then you do the Project reference(s).
The reason I said it is better is that:
VS will keep track of whether you're building Debug or Release and make sure the dll is consistent with the rest of the Solution.
The correct dll will (can) be automatically copied to the same folder as the rest of the Solution so everything is consistent.
The version of the dll Assembly will be consistent in the Solution. Especially useful for keeping track of things in Source Control.
(If you modify the dll, then you can be sure the rest of the solution is referencing the one you intend.)
|
|
|
|
|
Thanks! I'll get that fixed right away.
|
|
|
|
|
That's excellent! We've been having these problems (referencing wrong dll) for a while now! This will solve that!
|
|
|
|
|
Hello, I am using word automation in c#, no problem with merge fields but I need to do another action: I need to add to my Document a Header and a Footer from another document. Can you help me? Tanks a lot!
|
|
|
|
|
What have you tried?
Where are you stuck?
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Well, sorry but I dont'know ho to select header and footer from another doc and insert them into the other doc.
|
|
|
|
|
|
You can actually record a macro in Word doing what you want and you'll see the code you need. You'll just have to tweak it a little to work within your C# app.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
how to connect the fax modem with pc and bd
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
