Derek Stone

The more important consideration to make here is the validity of hiding or disabling properties, which you shouldn't even be attempting to do. It's poor object-oriented design and I strongly recommend re-evaluating your control's model.

Query HKEY_CLASSES_ROOT.

It proves that Windows XP was nothing more than a pitiful update to my superior copy of Windows 2000. ;)

No, not from ASP.NET.

The advantages are you can access the current user through Thread.CurrentPrincipal. This may not seem spectacular, and for all intents and purposes it isn't, but it's a much better solution than querying a custom security implementation which does nothing more than to duplicate the existing functionality of the framework. In other words there's no point in redoing what's already available. It is not "complicated" to implement at all and fits in very easily with custom security schemes. It doesn't "limit" you in any way as its nothing more than a simple interface which needs implementing. You can add whatever you like to your principal class as long as it implements the IPrincipal members. Additionally, if all you need is a basic IPrincipal implementation simply use the GenericPrincipal class.

That and most people don't have a clue what's good for them anyway... :)

That article is pretty much the bible of Web service efficiency. It doesn't get much better than the optimizations described therein. However since you're more interested in HTTP posts you'll need to focus on the portion of the article in which the PreRequestHandlerExecute event is implemented. The code in the article can be easily modified to work for a Web request instead of a Web method invocation. The key to optimizing in situations where there are long blocking calls is to remove them from the ASP.NET worker thread onto a background thread that won't halt the chain of execution. PreRequestHandlerExecute is the best way to do just that.

That's fine assuming you want to instantiate a new instance of your BLL everytime it needs accessing. Generally BLL methods are kept static for ease-of-use. Bungpeng-- you need to implement IPrincipal if you wish to use the method I suggested. I'm assuming you have a user object of some sort which can implement IIdentity from. You can then initialize either a GenericPrincipal object with the User class (which you'll program to implement IIdentity) or manually implement IPrincipal. Public Class User Implements System.Security.Principal.IIdentity Dim _Name As String = String.Empty Dim _Password As String = String.Empty Dim _IsAuthenticated As Boolean = False Dim _AuthenticationType As String = "Custom" Public Property Name() As String Implements System.Security.Principal.IIdentity.Name Get Return _Name End Get Set(ByVal value As String) _Name = value End Set End Property 'Name Public Property Password() As String Get Return _Password End Get Set(ByVal value As String) _Password = value End Set End Property 'Password Public Property IsAuthenticated() As String Implements System.Security.Principal.IIdentity.IsAuthenticated Get Return _IsAuthenticated End Get Set(ByVal value As String) _IsAuthenticated = value End Set End Property 'IsAuthenticated Public ReadOnly Property AuthenticationType() As String Implements System.Security.Principal.IIdentity.AuthenticationType Get Return _AuthenticationType End Get End Property 'AuthenticationType End Class 'User HttpContext.Current.User = New GenericPrincipal(New User(), New String() = {"CustomerService", "Transactions"})

http://www.xtremedotnettalk.com/showthread.php?s=&threadid=69454#post368172

Interop.TDCIPH32 is your runtime callable wrapper (RCW) generated from the type library that describes your COM DLL. Your best bet may be to modify the typelib to accept a byte array and then recompile the RCW manually using TlbImp.exe. Alternatively you could use TlbImp.exe to produce the RCW's IL which you could then modify to accept an ANSI string.

You can only access controls on the UI thread from an auxiliary thread by calling the Control.Invoke() method, passing in a delegate and an optional array of parameters.

Add to that the quirks when logging into the news server... But hey, at least you can use the SDKs. I can't until my copy of Visual Studio .NET 2003 comes in the mail.

Smart navigation only works when posting back to the same page. Its advantages/disadvantages are clearly stated in the .NET SDK: "Smart navigation is an ASP.NET feature that is supported in Internet Explorer 5.5 and later browsers. It allows a page to be refreshed while maintaining scroll position and element focus between navigations, causing only a single page to be stored in the browser's history, and without the common flicker associated with refreshing a Web page. Smart navigation is best used with ASP.NET pages that require frequent postbacks but with visual content that does not change dramatically on return. Consider this carefully when deciding whether to set this attribute to true." - .NET Framework SDK Documentation

Did you go for the free VSIP, the $3000 version or the I-need-to-remortgage $10,000 package? ;)

Store the current principal (the user) in the HttpContext.Current.User property. You can then access that user in your DAL via that same property or via Thread.CurrentPrincipal.

Place the following in your Web application's configuration file (web.config): <identity impersonate="true" />

I get roughly 140 FPS running your example Nerseus. Don't I feel special. :)

Under the rare conditions that more than a few INSERTS would need to be executed you'd create a batch insert, not execute them one by one. A scenario like this is rare though, and I've never had the inkling to even bother creating an insert test. A few tips to keep inserts as fast as possible: The more indexes on the table the slower inserts will be. Keep column lengths as narrow as possible. Use RAID 10 or RAID 1. According to Microsoft employees RAID 5 is very slow on inserts.

Very few of the current Web browsers support the specifying of file types in the file input tag. You're pretty much out of luck in that regard. You'll have to filter at the server.

Your code looks fine. It appears you're the lucky recipient of BUG 320079. Congratulations! Seriously though... the binary formatter has a known problem with deserializing structures, arrays of structures and nested structures. I strongly suggest you convert to classes, which is the only true fix I've been made aware of.

Forgive me, but wouldn't remoting be more appropriate for a dsitributed application? Or are you referring to debugging one process from another? And would the debugger run on local or remote processes? Or both?

Yes. The MSDE installer comes with built-in support for silent installations. If you have a frontend for the data, then yes, I'd recommend MSDE. .NET. I don't understand why you'd even bother using ADO. Use ADO.NET.

HttpWebRequest allows the developer to create specific requests. WebClient is far more generic and may just work for you.

There's absolutely no reason to use Access. Contrary to what Nerseus said internal reports from Microsoft indicate that Access won't be supported in the near future. SQL Server has and will be around for years to come, meaning that MSDE will most likely be as well. All MSDE is is a recompiled version of SQL Server optimized for 5 or less concurrent users. There is also a 2 GB database size restriction, but that is hardly a problem for most businesses. I recently moved my accounting system from Access to SQL Server and I'm very glad I did. Access is a horrible multiuser solution, simply put-- concurrency and corruption issues plague it. The only reasons why developers have a hard time using MSDE is because they a) don't realize it exists, b) don't want to go through the "hassle" of installing MSDE on a client's systems. These are hardly excuses. They're poor development choices.

Are those structures marked as serializable?