It's probably just a case of me not looking in the right place or not seeing the obvious, but does anyone know if a machine with just version 2.0 of the .NET Framework should be able to run a VB.NET Express application which accesses a SQL Server Express database file Or is there an additional requirement for a non-development machine to have some kind of SQL Server Express runtime component in addition to the 2.0 Framework
It seems to be counterintuitive to expect that a VB.NET application would be able to access any kind of SQL Server data without having some kind of SQL Server host component (Express or otherwise) installed. But then again, it seems just as counterintuitive that Microsoft would require the download and installation of the new framework as well as a separate database runtime in order for the average user to run an application with accesses a local SQL Server Express database.
To me, it runs contrary to the whole concept of XCopy deployment to require more than just the application's files and .NET Framework for an application to run properly. But nothing I've read so far explicitly indicates that a user would require anything more than the app files and the framework to run an application which accesses SQL Server Express data. But...I can't get any VB Express applications which uses a SQL Server Express databases to run on any machine that doesn't have SQL Server Express installed.
What am I missing
(Apologies if this isn't the right group to post this in. It seemed most appropriate given the choices.)
- Mitchell S. Honnert

XCopy deployment of a VB Express app which uses a SQL Server Express database?
MattAster
>to make it very easy to get all components installed.
Thanks. I'll give this a shot. It sounds like this will make things much more clear on what components are required on the destination machine.
On a related note, I'm most curious about the footprint of the installation. I have to admit that one of the great appeals of the .NET architecture for me was the ability to simply copy a set of relatively tiny files over to a destination machine and just have the app work. The evidence was staring me in the face, but until you confirmed that using SQL Server Express breaks this typical view of XCopy deployment, I didn't want to draw the final conclusion.
>I'll be writing more about local data on my blog.
>Stay tuned - and hope this helps.
It does help indeed. Thank you very much. And I will check out the blog. I'm sure it will answer some of the lingering questions I have on this topic.
- Mitchell S. Honnert
John Simpson 2000
First, let me answer this directly. If your VB.NET app uses a SQL Express local database file (.mdf) you need SQL Express on that destination machine. Therefore you need .NET Framework 2.0 and SQL Express on the destination machine. I suggest you build a setup using ClickOnce deployment (via Publish command) to make it very easy to get all components installed.
Just like you point out, SQL is needed to be the engine that manages connections, loading, saving, etc. The .NET Framework is capable of connecting to database servers / engines, but it is not an engine itself.
In the past we had Jet performing a similar duty. Jet was seemless because it eventually was shipped as a standard driver in the Windows platform. Xcopy of .mdbs always works b/c Jet is always there.
In .NET you can think of SQL Express as a logical extension to the .NET Framework and platform. With the logical extension in place, xcopy just works. But SQL is not tightly coupled to the .NET Framework redist. Moving forward, you may see more unification, but for now we've kept the pieces separate. This is as lean and mean as possible. Although, I agree it's a bit more of a burden to deploy both pieces on a target machine. Again, ClickOnce can help make this very easy for you.
I'll be writing more about local data on my blog. Stay tuned - and hope this helps.
http://blogs.msdn.com/pauly
thanks,
Paul