From Don Kiely

The Code Generation Network‘s Jack Herrington recently interviewed Kathleen Dollard about code generation, her new book (Code Generation in Microsoft .NET), and the state of programming in general and .NET specifically. It’s an interesting read; Kathleen has some interesting thoughts about where programming should go.

Read the interview here. I’ve been using her techniques along with Rocky Lhotka’s CSLA framework (the book and his site) for my current projects, and it’s a sweet combination.

Incidentally, Kathleen also has her code generation Web site up and running. Check it out!

Oooh I am so looking forward to the dataset merge and datatable merge functions in Whidbey.

In the meantime, I have some little functions that I use in my .net apps to do this. This topic came up in our user group meeting last night and I mentioned my work around and many people asked me to share the code with them. It’s not a big secret – the trick is two-fold. 1) Accept the fact that a datatable that is part of a dataset is superglued, stapled, chained for life to that dataset and cannot be added to any other dataset. Period. The only way to detach it is to kill it and once it is dead it can’t be married to another dataset anyway. 2) check out importrows!

So here is my routine, and it is overloaded.

Public Function MoveTabletoNewDS(ByRef DestDS As DataSet, ByRef SourceTBL As DataTable)
   Dim newTable As DataTable = SourceTBL.Clone
   newTable.TableName = SourceTBL.TableName
   Dim oRow As DataRow
   For Each oRow In SourceTBL.Rows
     newTable.ImportRow(oRow)
   Next
   DestDS.Tables.Add(newTable)
End Function

This overload is so that I can also work with strongly typed datasets. I want to pull a datatable out of one dataset and put it into another strongly typed dataset.

Public Function MoveTabletoNewDS(ByRef DestDS As DataSet, ByRef SourceTBL As DataTable, ByRef NewTable As Object)
   ‘newtable has been created from a strongly typed object
   newTable.TableName = SourceTBL.TableName
   Dim oRow As DataRow
   For Each oRow In SourceTBL.Rows
     newTable.ImportRow(oRow)
   Next
   DestDS.Tables.Add(newTable)
End Function

Here’s the home page for Christoph who did the OpenHack demo at DevDays in Houston.

Here are some recent entries – he is following up from his talk (and questions he was asked) at DevDays and with more info and how-to’s

• DevDays:Restricting access to IIS websites.
• DevDays: A simple way to configure a domain account to access the database
• DevDays: OpenHack and encrypting the encryption key

Well that quote comes from this post (On the Road to Indigo – is .NET REmoting Dead?) by Microsoft’s Rich Turner and it caught my eye. In it, Rich explains the future of .NET Remoting.

I personally don’t have a lot of (well…any) experience with .NET Remoting. Once I got through the learning curve of web services (since that was what MS was pushing at the beginning of .NET) I got lazy and used web services even in situations where I knew that .NET remoting would have been more efficient.

So when I was at PDC listening to Don Box talking about Indigo and saying that if you want to use indigo, just keep using web services and and forget about remoting. I felt so justified. But according to Rich, I (like many, I am sure) missed the point.

So if you are using .net remoting and concerned about it’s future, go checkout Rich’s post because I am NOT the person to be explaining this to you.

My jam-packed session at DevDays – Defenses and Countermeasures – shows a huge amount of solutions of things you can do to try to keep the hackers out. It was frustrating not to be able to get into the details of all of the great information that was in there due to the time limitation.

I think it would be interesting to look at all of those lessons in tiers.

The first tier would be basic, easy to remember, somewhat easy to implement solutions like:

• never use sa as the account to access your database
• use integrated security to access your database when you can, however if you *must* use uid & pwd your db access strings, hide them. THere are a number of ways including: use the configuration applicaton block which has this ability built via a wrapper to DPAPI OR encrypt the string yourself before putting it in your web.config file (in .net 1.x you will need to build your own little dpapi library to help you do this as well as to decrypt) OR encrypt to string and stuff it into the registry
• check query strings in URLs to make sure they don’t include possible sql injection strings – this is pretty easy to just do in the page load
• use stored procedures FIRST, paramaterized queries as a 2nd option and concantenated queries never
• validate data entry to limit possiblity of characters that are used for sql injection or cross-site scripting attacks
• never use the system account for your web application
• htmlencode all output back to the browser

Even with this top tier list, there are two audiences. The first audience only needs the list and either know how to accomplish these things or knows how to find them. That audience just wants a check list, then you can also talk about a LOT more things. THe other audience would need this list to be the entire one hour presentation so you can really dig into each thing – how to do the encryption, looking at the difference between the effect of a query string with a sql injection attack and a stored procedure with the same attempted sql injection attack, experiment with the variety of other ways to prevent nasty input.

I will be thinkig about all of this a lot until the next DevDays  (in Boston) where I will presenting this session again.

I am getting some great feedback in my last two security related posts from people who have been thinking about, working with and dealing with asp.net security a lot longer than I have.

DEFINITELY read the comments by Steve Smith and Sam Gentile in my last post.

And don’t miss the comments by Anil John and Andrew Duthie in my post on  the RequestValidation feature in ASPNET 1.1.

There is no ONE solution to security. Threats are coming at you from many many angles. You have to protect yourself in many many ways and then you still won’t be done.

One of the points that is made in the Defenses and Countermeasures session that I am doing for DevDays is that what we are doing with all of these steps is not assuming that we are eliminating all security problems, but instead, we are continuously raising the bar for potential hackers. Making it harder and harder for them to do their deeds.

Don’t we all? Isn’t it what we were told to do. ASP.NET protects the web.config file so nobody can browse to it and see your connection strings, logins and passwords and whatever else you have hidden in there. Right?

But guess what, that’s just not good enough anymore! Hackers who know how to get into your webserver and get around asp.net can get at the web.config file.

This is one of the things we are talking about in the DevDays ASP.NET Security track.

One of the ways to protect the strings is to encrypt them (which isn’t so hard) but decrypting them *is* (and should be, if you think about it…). DPAPI (a win32 api – not managed code) is used to handle the keys for encrypting and decrypting your data but it is pretty confusing to use especially if you are not used to dealing with unmanaged code. (In that case, if you want to get more comfy with that, keep up with Sam Gentile’s MSDN series on COM Interop.)

Enter the Configuration Management Application Block for .NET . Among it’s features is it’s ability handle this encryption/decryption for you.

How does the Configuration Management Application Block improve the security and integrity of application configuration data?

Regardless of the type of data or the store in which the data is held, you can configure the Configuration Management Application Block to use the data signing and encryption services provided by a Data Protection Provider. The Configuration Management Application Block provides two Data Protection Provider implementations and the extensible architecture of the Configuration Management Application Block means that you can easily seamlessly integrate your own Data Protection Provider implementation

Phew! (You’d be saying that too if you looked at the code for working with DPAPI.)

Also – Whidbey will have a managed wrapper for DPAPI so a lot of this will be easier to do yourself down the road. My understanding is that this is actually related to the work that was done for the App Block. (Or maybe the other way around?)

Did you know that ASP.NET v1.1 automatically checks for possible scripting attacks when users enter info into you forms? I didn’t! I learned it in my prep for my DevDays session.

So this:

(with Errors =”Off” in web.config) results in this: (click to enlarge)

This protection is on by default. It is controlled in a few places. See this article on Microsoft’s ASP.NET site for more details.

This is probably old news to many who have been playing with VB.NET Whidbey for a while…

I noticed that when debugging, if I didn’t have have NEW in a custom class, the debugger stops on code that instantiates that class, givint a little popup message “There is no source code for the current location.” You can hit okay and then just continue and all  is fine. This is not affected by Option Explicit or Option Strict settings.

Probably something that has been duly noted by now. I wish I had time to do this stuff this summer when it would have been useful for the VB team.

Scott Nonnenburg, the Debugger PM, just posted a blog about visualizers and it’s not just a teaser it’s is a how-to.

Oh this is torturous! I want to drop everything and go play with this, now!