The name of the DLL (or assembly) is completely unrelated to which namespaces the types it implements are in. The 'core' namespaces are spread between mscorlib.dll and System.dll. The most critical ones that are required for even the most basic bootstraping are in mscorlib.dll. This isn't just the System namespace, but Collections, IO, Reflection, Remoting, Serialization, Security, etc. The ones that other things don't depend on as much and hence may never need to be loaded are in System.dll. This includes CodeDom, ComponentModel, Net, RegularExpressions, etc. Don't let the names of the other DLL's fool you either, for example System.Data.dll mostly implements types from the System.Data namespace, but it also implements some types that are in System.Xml and so forth. -Blake

CopyFileEx is not a COM method, it's just a plain stdcall API function. Same thing with it's callback, there's no interface there at all, just a function pointer to a stdcall function. Nothing to marshal. -Blake

graphics.FillRectangle(new SolidBrush(Color.FromArgb(80 ,SystemColors.Highlight)), imageRect); graphics.DrawRectangle(SystemPens.Highlight, imageRect); -Blake

Change your OpenChromeless function to take the window name as a parameter as well and be sure it returns true so the form submit is not cancelled. Then you can use something like: <form action='foo.aspx' method='get' onsubmit='OpenChromeless("about:blank", "MyFormResults")' target='MyFormResults'> -Blake

\d{1,10}(?:\.\d{1,3})? Notes: ~ Use \d instead of [0-9] ~ Use ? instead if {0,1} ~ Group the decimal and the following digits so either both or neither must appear. ~ This presumes that you want "123" and "123.1" to be valid, but "123." to be invalid, change the second 1 to a 0 if that's not true. ~ Keep in mind that you need something before and after that expression as well to delimit it. If your numbers were each on a line by themselves, then a ^ on the front and a $ on the end would work. But you need to avoid matching 991111111111.1119 the valid number in the middle of the bigger number there. -Blake

I'll add another vote for the general solution that Heath already sketched out. In addition, here[^] is some sample code to do exactly this which I posted last week in answer to someone else's question. To answer your other questions: Yes, you can read and write on the same socket at the same time. Leave the connection open, a single connection doesn't consume enough resources to care about. You should, however, be prepared to handle connection failures and go back into listening state to wait for the client to reconnect, incase of transient network failure. No, you don't need to use multiple threads given that you have a single client. (There is an advanced case where it might be useful to use multiple threads with one client, if you want to send your requests to the mainframe asynchronously, i.e. submit a second request before the result of the first one has been recieved. If your transactional performance is already adequate, then don't complicate life by doing that.) One last pointer, checksums are your friend: System.Convert.ToBase64String( System.Security.Cryptography.SHA1.Create().ComputeHash( System.Text.Encoding.Unicode.GetBytes(yourData))) -Blake

Did you actually read his question? Heath Stewart wrote: 1. If you're connecting only to SQL Server and not any other DB systems, use the System.Data.SqlClient instead of OLE DB. These are classes written specifically for SQL Server with a lot of optimizations and additional features over OLE DB. His data access is being done from a COM dll, not a .NET component. You are answering the wrong question. Heath Stewart wrote: Typically, most Windows Services use the LocalSystem account. If your connection string is using SSPI and the LocalSystem (SYSTEM) account is NOT added to SQL Server as a viable user that can access the system, you'll get Access Denied. He is very clear about the fact that he is _not_ running the service under LocalSystem. Heath Stewart wrote: Typically, most Windows Services use the LocalSystem account. If your connection string is using SSPI and the LocalSystem (SYSTEM) account is NOT added to SQL Server as a viable user that can access the system, you'll get Access Denied. He's also very clear that the database is on a remote machine, in which case granting LocalSystem access won't help at all because they are two unrelated LocalSystem accounts. Heath Stewart wrote: You should either use a fixed User ID and Password in the connection string, as well as Trusted Connection *sigh* I'm not even going to go there. Fortunately Terry's answer already homes in on what is likely the real problem. -Blake

While it is counter-intuitive, what you want in this case is UnicodeEncoding.GetString(byte[]). Because the data inside a string is natively stored using that UnicodeEncoding, it is a null transform, leaving your bytes alone. (I suspect you'd better have an even number of bytes in your array if you want this to work. Herein lies a subtle inconsistency between BSTR's and System.Strings. BSTR's kind of admit to being used to pass random data around, and hence support odd numbers of bytes even though they are supposedly a strings of 16bit values. Your API hopefully won't care if you pad an extra null on the end if the length was odd.) -Blake

Mark Nischalke wrote: Pratice what you preach Blake. But you forgot to quote the rest of what I said in that post, Mark. Blake Coverett wrote: I don't have a problem with people who don't know things, after all there's lots I don't know, but I have no tolerance for aggressively stupid people who won't learn when taught. If the shoe fits, wear it. -Blake

Heath Stewart wrote: I hate to burst your bubble, but while you are correct about using the Files property as being "standard" (which there is no "correct" way), I am also right. Now now Heath, that sort of hostility is unnecessary. The very first line of my message said "assuming we are talking about standard upload with an <input name='foo' type='file'> tag". Since the original poster didn't specify any custom client software it is a very safe assumption he is just using the browser and and HTML form to upload with. The fact is, your answer was wrong for the most common way to upload files. Heath Stewart wrote: RTFD, or know from experience like I do, which is also based on reading the RFCs. I am intimately familar with the RFCs, thank you, and have written code that does this many times, starting back when I had to write my own ISAPI to handle the data. Heath Stewart wrote: It just depends on how you send the file. *chuckles* Right... which translates as, as long as you write code to ensure you set the Content-Type header correctly on the client, then you can depend on checking it on the server. But you failed to mention that in your answer, didn't you? Quick Quiz: if you use System.Net.WebClient.UploadFile(), does it sniff the data and set your Content-Type header correctly? How about MSXML2.XMLHTTP.4.0? Looks like you've just moved his problem to the client code instead of the server code and not helped him at all. -Blake

Tsk, tsk, tsk. Are you actively trying to look more stupid here? Mark Nischalke wrote: Given the criteria of finding the base folder for a page, then query strings on the url make no difference. Incorrect, the Request.Url includes the query string and the fragment identifier. Any attempt to extract the base folder needs to take that into consideration. Mark Nischalke wrote: Still waiting for the exception. Read what I said, you will get either an exception or the wrong result. Either/or, that's one of those tricky English phrases, it means you will get one of them. 1) When the query string or fragment identifier contains a '/' or '\' you get the wrong result. 2) When the query string or fragment identifier contains a '|' or '>' or '<' etc an exception is thrown. All of these characters are perfectly legal in that part of a Uri.

using System;
using System.IO;
class MarkIsEvenMoreStupidThanIThought {
static void Main() {
Uri wrongResult = new Uri("http://foo.com/bar/baz.htm?x/y");
Uri exceptionThrown = new Uri("http://foo.com/bar/baz.htm?x>y");
Console.WriteLine(
Path.GetDirectoryName(wrongResult.ToString()));
Console.WriteLine(
Path.GetDirectoryName(exceptionThrown.ToString()));
}
}

So, are we completely clear now? System.IO.Path fails to properly parse perfectly legal URLs, giving either the wrong value or throwing an exception. I don't have a problem with people who don't know things, after all there's lots I don't know, but I have no tolerance for aggressively stupid people who won't learn when taught. -Blake

It would be HttpRequest.Files["foo"].ContentType that he should check, assuming we are talking about standard upload with an <input name='foo' type='file'> tag. IE does set this ContentType header (which isn't an HTTP header, it's a MIME header in one of the body parts of the content) but it seems unwise to rely on that. I would suggest something like:

bool IsBitmap(string tagName) {
try {
using (Bitmap b = new Bitmap(HttpRequest.Files[tagName].InputStream));
} catch {
return false;
}
return true;
}

Alternatively, if you don't want to pay the cost of parsing the whole image, you could just look at the first few bytes. All of the likely image types have easy to parse signatures in the header. A quick glance at each spec will give you the details. -Blake

Sorry, I forgot you wanted the site on the front too, better to use Request.Url.GetLeftPart(UriPartial.Path) instead of Request.Url.AbsolutePath. That gets you everything from the scheme through the path, not just the path. -Blake

using System;
class AClueForMark {
static void Main() {
Console.WriteLine(
Path.GetDirectoryName("http://foo.com/bar/baz.htm?x/y"));
}
}

Quick quiz - what does it print? -Blake

Mark Nischalke wrote: Add a couple of slashes to the address used to get here. Still gets you here but may not parse correctly if you are only expecting one. Wrong. Try it and you will see for yourself. As I already told you, System.Uri class canonicalized the URL. If I use http://foo.com/bar///test.aspx, yes I will get the same page as http://foo.com/bar/test.aspx, but the value of Request.Url.AbsolutePath will be /bar/test.aspx with the extra slashes removed in both cases. Mark Nischalke wrote: System.IO.Path does handle it. System.IO.Path is for file system paths not URI paths. The two are not the same. Valid instances of one are not always valid instances of the other. In particular, System.IO.Path knows nothing about query strings or fragment identifiers. If you pass a valid Uri containing those into System.IO.Path you will end up with either an exception or the wrong result. Check your facts before you spout off next time. -Blake

Mine was funnier, even if later. :P -Blake

Windows API: The application programming interface (API) exposed by the windows operating system. In Unix terms this would be like the OS system call interface, excepting of course of the fact that the Windows API does everything, rather than having half a dozen different APIs you must code to, like Unix, X, Qt, etc. Win32: Coined to distinguish between the Windows API exposed by old 16 bit versions of Windows, i.e. Windows 1.0-3.11, and 32 bit versions, i.e. Windows 95-ME and Windows NT 3.1-Windows 2003 Server. Win32 is now a synonym for Windows API since the Win16 API is dead and forgotten. MFC: Microsoft Foundation Classes - the original application framework that Microsoft first shipped with their C 6.0 compiler. It is old and crufty and designed for C++ without templates or other modern features. It tries hard to force everything into the Model-View-Controller design pattern. ATL: Active Template Library - named in an era when Microsoft was sticking Active on the front of everything, like ActiveX, ActiveServer, ActiveMovie, ActiveBob. This is a newer library, designed primarily to support writing COM components in C++. It uses the language in a much more modern way than MFC, but doesn't cover nearly the same breadth of functionality. You can bold ATL and MFC together in the same application but it isn't really a great match. WTL: You missed this one, but it is important. This is a library build on top of ATL that broadens it's scope to make it closer to an application framework. It is much lighter and faster than MFC. It has an amusing history of being supported and then unsupported and then supported by Microsoft. COM: Component Object Model - This was born as OLE2, but left it's parent in the dust and is the standard binary component specification that virtually all Windows software was based around until .NET arrived on the scene. COM is dead, long live COM. -Blake

Mark Nischalke wrote: Correct they are for Windows File Systems and unless I'm missing something that is what you are using. Yes, you are missing something. mittalpa is correct. He is parsing a URL, not a file system path. They are not the same and code for one will not handle the other correctly. Mark Nischalke wrote: Using your method is inherently dangerous. Are you checking for valid uri before getting it or just hoping it is valid when parsed? The previous method uses built in exception handling of the class. What's the point of having a tool if you're not going to use it? No, his method is not dangerous. He is parsing the uri from the Request object, not some arbitrary one passed in from elsewhere, so yes, it has already been canonicalized and validated. (His code wouldn't be running if it weren't.) -Blake

You need to use AbsolutePath instead of AbsoluteUri. Try the perfectly valid "http://foo.com/bar.htm?baz=x/y" as an test case to see the difference. -Blake

This only works like a charm because you haven't tried it with enough test cases. See what happens if the user types a '<', '>' or '&' in your test box. Depending on various other code and configuation things you may find accented characters a problem too. Use XmlTextWriter, it is your friend. -Blake