January 15, 2008 at 8:04 am
This is a cross posting, sorry about that, but thought I'd see if had any luck here.
We have an desktop application that uses sql server as its back end. This app was developed using dotnet framework 2.0 in C#.
Our developer is claiming that in order to use the typical sql server connection screen (has drop down box of available sql servers on top, with refresh button next to it, then log in section (integrated or sql log in, then at bottom list of databases).
This screen only appears to work (our developer is claiming) if the computer our app is installed on has sql server 2005 SMO (basically the client tools). Now that doesn't make any sense to me, but I'm more of a production dba, not a developer, so am not sure.
Does anyone have any knowledge about this?
Thanks!!
maybe a better way of asking the question:
Does it make sense that a workstation app that uses sql server as a back-end, would need to have sql client tools installed on all the workstations that are going to use this app?
My thought is if the developer (using C# and .Net 2) is using namespaces/programming objects related to SMO, shouldn't the required assemblies or whatever be built into the application? As opposed to having to install sql client tools (or just SMO if possible) on every client workstation?
January 15, 2008 at 8:40 am
SQL 2K5 includes the SQL Native Client, which isn't included with the SQL 2000 tools, nor with W2K or XP. I think Vista has it, but that problem is likely that he's using the SQL Native Client, which is the way to connect moving forward, and you need to install this on other clients.
January 15, 2008 at 8:58 am
Thanks for the quick reply Steve. That's sort of what we thought, but it seems even if we do install the sql native client, it doesn't work, unless we also install SMO somehow (we think by installing sql client tools - whatever it's called in sql 2005, mgmt express or something like that). We don't want to have to make every workstation have to install client tools if we can avoid it.
Shouldn't the app have the necessary assemblies built into it, if he's using smo in the application?
January 22, 2008 at 10:42 pm
It may depend on how the application is written, but for the standard connection window you can test by creating an empty file with an extension of .udl, and then opening it. I believe that this is an OS function.
July 8, 2010 at 4:39 pm
Kevin, you are basically correct. Here's the way it works.
In general, there is no such thing as you "must" run xyz setup. Anyone can reverse engineer setup disks and put files, registry settings, etc in the right place. It's simply easier to use prebuilt and pretested components.
For the develper in C# or your .NET application, open the project and look at project references. These are the .NET and other DLL's required to run your application. Some of these are stored in the global assembly cache (GAC) found on the existing computer, they can come from anywhere, but usually from an installer (MSI) downloaded as part of the .NET framework or installer from another source like SQL Client tools, visual studio, or 3rd party tool.
You can install an assembly anywhere on the target PC, but common assemblies usually go in the GAC.
Once you figure out the name of the assembly they used (for example Microsoft.Sqlserver.Smo) then you can determine the best way to deploy it.
Creating a msi installer in .NET is pretty simple and the setup wizard will detect these dependencies (like the .NET framework) and add them to the setup project for you. Some are included as merge modules as part of the Visual Studio package.
Determining dependencies of dependencies can be tricky and sometimes its easier to use a tested package to get the 1 or 2 items you actually need. You can make web searches of assemblies to find out where to get installer modules, etc.
To see what .NET assemblies are installed go to C:\windows\assembly to get the name and version. If this list does not match the assemblies needed by the appliction then the application will trigger an exception when they attempt to use an object that is not installed.
Note that developers can sometimes put a copy of the assembly in the application folder, in addition to having a different version in the GAC.
Cheers
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply