April 2005 - Posts
This link should tell you. We've seen this behavior one time too many.
http://www.dotnet247.com/247reference/msgs/28/140793.aspx
I was poking around Google looking for a quick and simple Help About Form implementation. I found Jeff Atwood's AboutBox on the CodeProject site
www.codeproject.com/vb/net/aboutbox.asp
I downloaded the source, and within 10 minutes had it up and running in our application.
We have tweaked it a bit to fit our application, though out of the box this is a very nice form. Great job Jeff and many thanks for saving me the time to implement this.
Here are some lessons learned this week when I set up SSL on our development web server for our .NET remote server, hosted by IIS.
Our windows forms client uses a remote server hosted by IIS. We want to encrypt the data sent to and from this remote server.
I first went to Verisign's web site and got a 14 day trial certificate. I then did some research on what is SSL and how to use it. Ingo Rammer was kind enough to help with this research. Thanks Ingo. Most of the below is taken straight from Ingo.
SSL supports two different modes of operation: encryption and authentication. Encryption is the default and "always on" if you will. The most common way of using SSL for authentication is to use a server-side certificate so that the client can authenticate the server. Am I really talking to who I think I am talking to?
You can also use SSL to authenticate the *client*. In this case, the client also needs a certificate. The client can then send the certificate as a credential instead of using his username and password. In our case, we want to use the first mode of operation: a server-side certificate should ensure that the client is talking to the right server *and* SSL should be used to encrypt data. As soon as you use an HTTPS url, this automatically works.
The checkbox "Require Client Certificate" switches to the second mode: the use of client-side certificates to authenticate users. That's also the reason why you're getting HTTP 403 errors: simply because your server has now been configured to require a client-side certificate to be sent with the requests, but your client didn't send any (you'd have to manually add code for this). That's why the caller can not be authenticated and therefore the call not be authorized.
But in any case: as soon as you use an HTTPS-Url, you are running in "encrypted" mode. It's just that you use SSL only for encryption and not for client-side authorization.
When using the test cert from Verisign, install the CA Root on each client machine you plan to test from. Some kind of trial certificates are only valid if the client accepts (and installs) a specific CA-certificate. This will usually not be a problem with a real certificate, because then the root CA is already known to the client. (Internet Explorer gets shipped with a number of root CA certificates). Prior to installing the CA Root on all client machine, some worked and some got a "The underlying connection was closed: Could not establish trust relationship with remote server." error. Installed the test CA Root on the client machines in question resolved this.
We love paired programming in our shop. We have always had a problem with our chairs though.
This solves that problem.
Perhaps a dumb question, but with the introduction of the term "Exception" (at least to me) in .NET I find myself using this term instead of "Error".
Now, I have struggled with re-training users to think in terms of exceptions and not errors. Like "The System encountered a fatal exception" vs a
"fatal error".
Am I the only one thinking like this? If not, would we be confusing users if we starting talking about exceptions vs. errors?
Like "Send me a copy of the exception" or, as our application does "The exception has been emailed to support". Will this confuse users and, if it does, is this a good thing long term to get them thinking about exceptions and not errors?
Lesson learned yesterday,
IIS6 will not server files it cannot determine the mime type for. IIS6 determines the file type from the .extention of your filename, just like windows identifies a files type.
We No Touch Deploy our windows form application from a web server. It's always been a W2K web server. Yesterday we installed the app at a client site who is using 2003 server. All of the files would deploy from the web server accept one. When I looked in the IIS Log file I saw a 404 for this one file.
After list serving this and chatting with David Hill at MS and other folks on the DevelopMentor CLR LISTSERVS, we got it resolved.
Seems we need to add a mime type for this one file as IIS6 will not server up the file unless it's in it's mime list.
Good resource for this:
http://support.microsoft.com/default.aspx?scid=kb;en-us;326965
Capital Tech Search is looking for sharp .net developers. They have a client that has upwards of 3 openings right now. The pay range is 60-75k. The three biggest technologies involved with the position are: vb.net, asp.net, and sql server 2000.
Contact:
Tommy Edelblut Jr.
Technical Recruiter
(804)282-8788 x218
capitaltechsearch
Let him know you read about this on my blog.
I am tired of writing (and seeing) code that looks like this in our application:
If myString.Trim().ToUpper = "O"
or something like this:
If String.Compare(myString, "O", True, New System.Globalization.CultureInfo("en-US") = 0
So, I wrote a 1 line utility method:
Public Function StringsAreEqual(ByVal string1 As String, _
ByVal string2 As String) _
As Boolean
Return String.Compare(string1, string2, True, New System.Globalization.CultureInfo("en-US")) = 0
End Function ' StringsAreEqual
More Posts
Next page »