locked
Application cannot load SQL SMO version 10 RRS feed

  • Question

  • Hi,

     

    I have a simple application that uses SQL SMO to print out version of the SQL Server. It was build on a machine that has SQL SMO version 9 installed. (The source code is listed at the bottom of the post).

     

    When I run this program on a machine that has SQL SMO version 9 (which was installed with SQL Server 2005), everything works OK. The programs prints out the correct message. But I get the following error if I use it with SQL Server 2008 and SQL SMO version 10:

     

    C:\>sql_test
    System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.SqlS
    erver.Smo, Version=9.0.242.0
    , Culture=neutral, PublicKeyToken=89845dcd8080cc91'
    or one of its dependencies. The system cannot find the file specified.
    File name: 'Microsoft.SqlServer.Smo, Version=9.0.242.0, Culture=neutral, PublicK
    eyToken=89845dcd8080cc91'
       at CallSmo()
       at main(String[] args)

    WRN: Assembly binding logging is turned OFF.
    To enable assembly bind failure logging, set the registry value [HKLM\Software\M
    icrosoft\Fusion!EnableLog] (DWORD) to 1.
    Note: There is some performance penalty associated with assembly bind failure lo
    gging.
    To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fus
    ion!EnableLog].

     

    As you can see that the application is looking for SQL SMO version 9. Why does not it use SQL SMO version 10 that is installed on the machine? I see the assmebly in the "C:\Windows\Assembly" folder and Microsoft SQL Server Management Studio works correctly. I am using Windows 2008 EE 32-bit.

     

    Any assistance would be greatly appreciated,

     

     

    Code Snippet

    #include "stdafx.h"

    #using <Microsoft.SqlServer.ConnectionInfo.dll>

    #using <Microsoft.SqlServer.Smo.dll>

    #using <Microsoft.SqlServer.SqlEnum.dll>

    #using <Microsoft.SqlServer.SmoEnum.dll>

    using namespace Microsoft::SqlServer::Management::Common;

    using namespace Microsoft::SqlServer::Management::Smo;

    using namespace Microsoft::SqlServer;

     

    void CallSmo()

    {

       Microsoft::SqlServer::Management::Smo::Server ^ srvH =

          gcnew Microsoft::SqlServer::Management::Smo::Server();

       System::Console::WriteLine(srvH->Information->VersionString);

    }

     

    int main(array<System::String ^> ^args)

    {

       try{

          CallSmo();

       } catch (System::Exception ^e)

       {

          System::Console::WriteLine(e->ToString());

       }

       return 0;

    }

     

     

     

    Thanks,

     

    Mark

    Wednesday, January 23, 2008 11:44 PM

Answers

  • SMO 2005 (the 9.0 version) will be updated so that it can connect to Sql Server 2008. I'm trying to confirm the current availability of that, but it already should be available or will be for sure by RTM of 2008. The 9.0 version of SMO will not expose the extra features that 2008 has, it will be the same API and just work against 2008... OK, there might be a couple of oddities that don't work but the all the mainstream stuff will just work. A simple rule of thumb is if the equivilent 2005 TSQL would work on 2008, then the SMO features should work too.

     

    SMO 2008 (the 10.0 version) will connect to a Sql Server 2005 or a 2008 server. This will give you the full access to both the 2005 features and the 2008 features. However it will require you to make some changes to your application. Most of these should be minor (additional references for example) but we aren't done yet so I don't know for sure all the changes required. Of course it will also depend on if we changed the API in the area you are using.

     

    I don't know what that list is yet so don't ask . As soon as we know we will have it available.

     

    Hopefully this makes some sense.

    Thursday, January 24, 2008 10:32 PM
    Answerer

All replies

  • Hello,

     

    Could you try to add a reference to Microsoft.SqlServer.SMO version 10 and not 9.00.242.0 ?

    Right click on refrences and you try find the version 10 of SMO ( be careful you have to do same thing with ConnectionInfo,etc

     

    Be careful, in a very recent post ( sorry for the answerer i can't remember ) SMO 2008 is not stable as the definitive is not released ( i found http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2723613&SiteID=1 )

     

    Have a nice day

    Thursday, January 24, 2008 12:06 AM
  • Thanks for replying.

     

    Do you mean adding location Microsoft.SqlServer.SMO version 10 to refeferences (LIBPATH) in the developer studio?

     

    I would like to use my existing application with SQL Server 20008 without rebuilding it. The posted program illustrates how a bigger application uses SMO.

     

    I added reference to SQL SMO v10 and rebuild the program. Now, it works with SQL Server 2008 but fails with SQL Server 2005:

     

    C:\sql_test\release>sql_test
    System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.SqlS
    erver.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' o
    r one of its dependencies. The system cannot find the file specified.
    File name: 'Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKe
    yToken=89845dcd8080cc91'
       at CallSmo()
       at main(String[] args) in c:\sql_test\sql_test\sql_test.cpp:line 22

    WRN: Assembly binding logging is turned OFF.
    To enable assembly bind failure logging, set the registry value [HKLM\Software\M
    icrosoft\Fusion!EnableLog] (DWORD) to 1.
    Note: There is some performance penalty associated with assembly bind failure lo
    gging.
    To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fus
    ion!EnableLog].

     

    Thursday, January 24, 2008 12:51 AM
  • Hello,

     

    Which language are you utilising ? ( VB,VC# or VC++ )

    I fear you are using VC++ ( i've seen using strd...h )

    I stopped to use VC++ since the arrival of VC#2003 so i will not be very useful

     

    Have a nice day

     

    Thursday, January 24, 2008 4:55 PM
  • The posted program is C++

     

    Here the same code in C#; it has the same problem:

     

    Code Snippet

    using System;

    using Microsoft.SqlServer;

    using Microsoft.SqlServer.Management.Smo;

    namespace sql_test

    {

       class Program

       {

          static void Main(string[] args)

          {

              Server svr = new Server();

              Console.WriteLine(svr.Information.VersionString);

          }

       }

    }

     

    Thanks,

     

    Mark

    Thursday, January 24, 2008 5:47 PM
  • Hello,

     

    Allen White answered in a very recent post :

    SQL 2008 libraries and tools are still under development, and the SMO (and other) dll's which will be distributed with RTM will be enhanced from what we have at this point.  Once they finalize the libraries I believe they'll have a similar distribution package to what they have for SQL 2005

     

    I remember at the eve of Sql Server 2005 , SMO was not really working with many bugs. SMO was really usable after the arrival of SP1 and especially SP2.

    I hope that at the end of February 2008, we shall a nearly complete SMO library usable versus Sql Server 2005 and 2008

    without having to produce a version for 2005 and another one for 2008.

    As i had many problems after the installation of pre-release versions of Sql Server 2005 and VB 2005, i had to reinstall Windows, so i decide to install VC2008 and SQL Server 2008 Express in March only ( simple precaution )

     

    I'm confident with Microsoft, but my motto is "Wait and see"

    I know that you may be feeling frustated to be enable to use all the fonctionalities of VC,VB,VC++ 2008 or Sql Server Express 2008. But i prefer to have a stable version than discovering the going away of interesting fonctionnalities

     

    Have a nice day

     

    Thursday, January 24, 2008 6:20 PM
  • SMO 2005 (the 9.0 version) will be updated so that it can connect to Sql Server 2008. I'm trying to confirm the current availability of that, but it already should be available or will be for sure by RTM of 2008. The 9.0 version of SMO will not expose the extra features that 2008 has, it will be the same API and just work against 2008... OK, there might be a couple of oddities that don't work but the all the mainstream stuff will just work. A simple rule of thumb is if the equivilent 2005 TSQL would work on 2008, then the SMO features should work too.

     

    SMO 2008 (the 10.0 version) will connect to a Sql Server 2005 or a 2008 server. This will give you the full access to both the 2005 features and the 2008 features. However it will require you to make some changes to your application. Most of these should be minor (additional references for example) but we aren't done yet so I don't know for sure all the changes required. Of course it will also depend on if we changed the API in the area you are using.

     

    I don't know what that list is yet so don't ask . As soon as we know we will have it available.

     

    Hopefully this makes some sense.

    Thursday, January 24, 2008 10:32 PM
    Answerer
  • I will wait for the SMO updates. Thanks!

     

    Mark

    Friday, January 25, 2008 6:14 PM
  • I am having same problem. I have one application using smo 9.0 for SQL Server 2005, its working fine. But same application is not working for Sql Server 2008, with smo 9.0.

         I added the reference for smo 10.0 and built the application, now its working for Sql Server 2008, but failing for Sql Server 2005.

         Still SMO 10.0 is not compatible with Sql server 2005????????

         Hey barsik, did you get updated SMO???

     

    Please reply.

    Tuesday, October 14, 2008 10:05 PM
  • Hello all,

    We are experiencing essentially the same problem as Barsik and SanjayAswale.

    We have an application that builds against v9 SMO and works with SQL Server 2005.

    We do not redistribute the SMO libraries.

    We wished to have the application work with SQL Server 2008, but when we connect, we get the ConnectionFailure Exception "This SQL server version (10.0) is not supported."

    Thus we changed our build process to reference SMO v10 instead of SMO v9.

    Now our application works with SQL Server 2008, but when run the application on a customer computer with SQL Server 2005, we get the error "Could not load file or assembly 'Microsoft.SqlServer.BatchParserClient, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified."

    I understand that this particular error stems from the fact that Microsoft.SqlServer.BatchParserClient did not exist in SMO v9.

    What I am trying to understand now is:

    - has SMO 9 indeed been updated to work with SQL Server 2008?  (in which case we may need to update our SMO 9)

    - is SMO 10 indeed supposed to work with SQL Server 2005?  (in which case what is the best practice to resolve the library referencing at build and loading at runtime?)

    - and, as an extension to the previous question, is it necessary for us to manually dynamically load the appropriate library at runtime, or is this expected to be handled "behind the scenes" if we have the appropriate SMO updates and the right references in our project?

    Bruce Prang, are you still lurking on this thread, by any chance?  
    Friday, October 24, 2008 11:41 PM
  • [a bit of repetition as I try to re-describe the problem, a bit of new insight and information]

    As I investigate this issue (and become more familiar with Windows deployment in general and SMO and SQL Server in particular), I find I am able to describe our situation a little better (and more accurately).I now understand that in fact, when we package our application with InstallShield, InstallShield bundles our SMO references into our installer.  So I was incorrect earlier when I thought we were not redistributing the SMO libraries.

    In fact, we see these behaviours:

    1. If we reference SMO 9 in our .csproj, build our application, and install it on the test computer, we see SMO v9.00.3042.00 libraries have been copied into our application folder along with our own components.  This build will work with SQL Server 2005, whether local or remote.  (Note that in the local case, there will also be copies of v9.00.242.0 of the SMO libraries located in C:\Windows\assembly.)  If we run this build against SQL Server 2008 we get the ConnectionFailure Exception "This SQL server version (10.0) is not supported."  (This seems reasonable, since SQL Server 2008 did not exist when these libraries were released.)

    2. If we reference SMO 10, we see SMO v10.0.1600.22 libraries copied into our application folder. This confirms that we have RTM and not RC0 versions. This build will work with SQL Server 2008, whether local or remote. If we run this build against SQL Server 2005, we get the error "Could not load file or assembly 'Microsoft.SqlServer.BatchParserClient, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified." In the case of (2), we noticed that Microsoft.SqlServer.BatchParserClient was not among the SMO libraries copied by our build process, so we put in a little hack to copy this dll as well. Afterwards, if we attempt to test against SQL Server 2005 we get a similar error message, this time for Microsoft.SqlServer.BatchParser.

    Some specific questions fall out of this (aside from the general question of how to make this work as simply as possible):

    a) It's possible we follow this process and add hacks that will copy over each missing dll, but will we run into problems with platform-specific dlls?

    b) Now, I noticed that when we are testing our SMO 10 build against SQL Server 2005, the server is a local instance. Thus, there are v10 SMO libraries in our application folder and v9 libraries in C:\Windows\assembly. Can this be contributing to our problem?

    c) Has SMO v9 ever been updated to support SQL Server 2008? I have seen claims that it would be, but I have not been able to find a download that includes this support.

    Thanks to anyone with advice!
    Wednesday, October 29, 2008 1:34 AM
  • You should install all SMO bits using standard MSI's. You can find all of the 2008 versions here. http://www.microsoft.com/downloads/details.aspx?FamilyID=228DE03F-3B5A-428A-923F-58A033D316E1&displaylang=en#ADOMD.NET

     

    The 2008 version is likely what you should use as it will allow connection to 2005 and 2000. I can't think of many reasons why you would want the older one.

     

    On this page you want Microsoft SQL Server 2008 Management Objects. Make sure to pay attention to the other required packages.

     

    My guess is that this will fix your issues but here are a few more bits of info that you talked about.

     

    * SMO calls will bind to the GAC (\windows\assembly) before it ever binds to your local application directory. This is just raw Assembly loading, nothing to with SMO here. Lots of information floating around on assembly/fusion loading.

     

    * Connecting to a local sql instance or a remote sql instance is no difference to SMO or DLL loading. There is a *small* chance that connecting to a different version might cause a different JIT order which could cause some late binding to happen... but I don't think we do that in SMO anywhere. I think the issues you are pointing out are more to do with an older version of SMO being in the GAC and that being loaded. The file not found are likely because you don't have all the right files in the GAC.

     

    * The 2005 SP3 beta is available (http://blogs.msdn.com/sqlreleaseservices/archive/2008/10/28/sql-server-2005-sp3-beta-release.aspx). You could also install the latest CU which is mostly what the SP will contain. http://blogs.msdn.com/sqlreleaseservices/archive/2008/10/21/cumulative-update-10-for-sql-server-2005-service-pack-2.aspx. Any of these should contain the updated 2005 SMO. But as I mentioned above, you shouldn't need it.

     

    Hope this helps.

     

     

    Wednesday, October 29, 2008 2:54 AM
    Answerer
  • Hello Bruce,

    Thank you very much for replying to this thread.  Our challenges with simultaneous SQL Server 2005 and SQL Server 2008 support are holding up release of our application, and so your assistance is very much appreciated.

    As well, I apologize that because I am relatively new to the Windows and .Net platform, I am probably making incorrect assumptions (e.g. whether assemblies will be loaded from the local directory or global cache first), and also having some trouble articulating my problem in the language of the platform.

    In our previous release of our application, we supported only SQL Server 2005, and even then only on the local machine.  This meant that our decision to use SMO for database deployment did not cause any trouble for our customers, since the necessary SMO components would be installed when SQL Server 2005 was installed.

    In our new release of our application, we now support both local and remote database servers.  So now if the server is remote, the target computer no longer will have the SMO components installed.  In an effort to satisfy a product management request to not make our users have to "install more stuff", we used InstallShield to bundle the SMO libraries into our installer so that they are present in our application directory.  This was adequate for SQL Server 2005 local and remote support.

    Enter SQL Server 2008.  We would very much like to support {2005, 2008} x {local, remote}.

    From what you are telling me, the simplest way to do this would be to tell our user to please go install the SQL Server 2008 feature pack (particularly the SQLSysClrTypes.msi and SharedManagementObjects.msi).

    But of course we still have our product management request to not make our users do any more manual installations.

    This leads to some rather RT(F)M-level questions (because I am new to the platform and don't know where to find the manual Wink ): is there a reasonable and simple way to embed the SMO msi installation into our installation?  or to stuff our required assemblies in the global cache?

    Do you confirm that the problems we are seeing should relate the the v10 libraries being in our application folder and the v9 libraries being in the global cache on the target machine?  I take from your post that you believe that if we get the v10 libraries into the global cache on the target machine, then we should be able to link against the v10 libraries when building our application and then successfully run with both SQL Server 2005 and 2008.

    Should we expect any problems if both v10 and v9 libraries are in the global cache?  (e.g. if our application is installed on a machine with a local SQL Server 2005...)

    Thank you very much again for your assistance!

    Wednesday, October 29, 2008 7:25 PM
  • Regarding the msi files we would need to include, as well as SQLSysClrTypes and SharedManagementObjects, I presume we would also need the SQL Server 2008 Native Client.

    This adds two complications:
       - the native client is, well, native, and thus platform-dependent
       - the CLR types require Windows Installer 4.5

    Thus, including all these components and performing the necessary tests would heavily bloat our installer.
    Wednesday, October 29, 2008 7:41 PM
  • Hello,

     

    For Bruce :

    the SP3 for Sql Server 2005 is a beta-version ( for beta-testers ) and i do not know whether it is a good solution to install a beta version ( a RC0 or RC1 version would be surer )

    the official link is :

    http://blogs.msdn.com/sqlreleaseservices/archive/2008/10/20/sql-server-2005-sp3-coming-soon.aspx

    So at the end of the year ( December 2008 ? )

    According to me, i would prefer to wait for 6 weeks and to have a final version

     

    Could you explain how you "deliver" your application ?

    msi,Click Once or installshield ?

    Click Once : it is possible to have the install of SMO libraries as pre-requisites not to be embedded

    Msi : SMO libraries install may be embedded ( msi may be embedded in a msi but at least with VS Standard not express )

    InstallShield : i have not used it from 2005 so i prefer to say nothing than to tell an error

     

    Anyway, it is an interesting discussion ( i would need an answer ) but i am not sure that is the good forum ( except if programer specialists like Caddre,Allen , Jonathan , i stop here, the list is too long , accept to have a look on this thread )

     

    Have a nice day

     

    PS : i have just discovered the last post of Curious Developer so i edit my post

    Curious, you are right about the msi installer 4.5but i think that the 4.5 will replace the preceeding versions and will be compulsory in a few months

    I correct the msi installer must be at least 4.5.6001.22159 ( see PSS blog at the top of Get Started with Sql Server Forum )

     

     

    Wednesday, October 29, 2008 7:52 PM
  • Thanks for the clarification Papy. You are absolutley right, using the beta version of SP3 is NOT something that should be distributing and I beleive the EULA forbids it. I'm pretty sure that is true with the CU's too, but not 100%. You would have to check. I wasn't thinking too much about delivery, I must have missed it in the thread.

     

    Sql 2005 SMO and Sql 2008 SMO can live Sidy by Side (SxS) on a machine in the GAC.

     

    I am not an install guy so I can't really tell about the best way to embded, or click-once etc. But it is all possible. It might be worth starting another thread ina more relevent forum which focuses on just "how do I ensure the pre-reqs are installed/emdeded" or some such.

     

     

     

    Wednesday, October 29, 2008 8:00 PM
    Answerer
  • Hi again,

    Just as an aside to the main part of this thread, perhaps Books Online could be improved to better reflect the system requirements for using SMO?

    For example, http://msdn.microsoft.com/en-us/library/ms162167.aspx leaves the impression on the newbie that SMO only requires the native client and that the native client is included in .NET (thus implying the developer does not have to worry about installing anything other than .NET on the target machine).

    As well, http://msdn.microsoft.com/en-us/library/ms162161.aspx does not mention anything about the dlls that are reporting failures for us, such as Microsoft.SqlServer.BatchParserClient.
    Wednesday, October 29, 2008 8:04 PM
  • Thank you for your help and comments, including the information on installers and the upcoming SQL Server 2005 SP3.

    We build our installer using InstallShield, however I believe that it produces an exe that contains the msi for the application.

    We are trying the approach of bundling all these prerequisites (Windows Installer 4.5, CLR Types 10, Shared Objects 10, Native Client 10 x 3 platforms) in our installer and installing them.

    Q: Can anyone confirm that when we are selecting whether to install x86, x64, or ia64 Native Client, we wish to base this decision on the true underlying hardware platform, rather than the installed OS type?

    I am concerned our product management will not like the resulting installer size, however from our discussions this seems like the simplest and most reliable way to ensure the necessary components are installed without forcing our users to install them manually.

    The option of simply dynamically loading the desired version from within code has lost favour because it relies on one or the other version being present on the system, and in the case of a remote SQL Server, these libraries can only get on the system if we or our customer puts them there.

    Q: Now in theory, this bundling approach should install our prerequisites in the global cache.  What will happen if the customer is using a local installation of SQL Server 2005?  Will the 2005 and 2008 versions of the libraries live happily together in the cache?  Will one version supersede the other?  Will we be able to run okay, and will we accidentally destroy any other application that depends on the 2005 libraries?
    Wednesday, October 29, 2008 10:15 PM
  • Thanks for the feedback. I've sent this on to our doc folks.

     

    In addition you can use the "give feedback" links in the BOL and they do look at all of those and update the docs.

    Wednesday, October 29, 2008 10:17 PM
    Answerer
  • Bruce, Thanks for the clarification about Sql SMO 2005 and Sql SMO 2008 being able to live Side by Side in the GAC.  That is music to my ears.  Smile

    Now a question about version selection for assemblies...

    It was clarified earlier in this thread that the assemblies will be loaded from the GAC before they are loaded from our application folder.  I was glad to get that clarified because I did not know the search order for assemblies.

    If the assembly version in the GAC is lower than the version an application was built against, will the system keep searching, or use the version in the GAC?  (Our test results imply yes, because when we built against SMO 2008 and ran with a local SQL Server 2005, we received a side-by-side load exception for Microsoft.SqlServer.BatchParser, which was present in the GAC but missing in our application folder due to a deployment error during our test.)

    If the assembly version in the GAC is higher than the version specified in the reference, will the system keep searching, or use the version in the GAC?  (Our test results imply it will keep searching, because when we built against SMO 2005 and ran with a local SQL Server 2008, we appeared to load the SMO 2005 libraries, but it is worth confirming.)

    So then based on these test results, is it that the GAC is searched first but the search continues if the version does not match exactly, or is there any chance that in fact the GAC is not searched first?

    Thanks again for all your input!
    Wednesday, October 29, 2008 10:44 PM
  • Hello,

     

    Thanks to Arnie Rowland, i can give you a partial answer.

    For the moment :

    1) Sql Server forums will be moved from the "old forums" to the new ones http://social.msdn.microsoft.com/Forums/en-US/categories/ around the 15th of November

    2) it is impossible to move a thread from an old forum to a new one

    3) it is impossible to split a thread from an old forum to a new one

     

    Curious Developer , your question about the search order of libraries is very interesting and important for people who want to develop and to deploy SMO applications working with 2005/2008 Sql Server.

    I suggest you to create a new thread shortly explaining the problem on the forum Where is the forum for ?

    http://social.msdn.microsoft.com/Forums/en-US/whatforum/threads/

    I am sure that someone will very quickly indicate the name of the good forum

    When you will know the name of the good forum, i suggest you to post your question on it ( with a link to this current thread for a better understanding of the thread ) and to come back to this thread to indicate the link to your new thread ( so SMO/DMO forum visitors will know that the discussion is continuing on an other forum )

     

    I know it is complicate , but i don't how to do in an other way.

     

    We are waiting for your feedback to follow this interesting ( and useful ) thread

     

    Have a nice day

     

    Thursday, October 30, 2008 7:04 AM
  • Papy, I will endeavour to recreate this assembly loading question on the new forums soon.

    In the meantime, a quick update: We are attempting to bundle the SMO 10 redistributables in our installer, but during packaging InstallShielf complains that our build machine is missing the C Runtime library msvcr80.dll version 8.0.50727.1833.  The build machine has a few versions of this file (8.0.50727.42, x.762, etc.) but not x.1833.  I am not sure which Visual Studio redistributable to download to get x.1833 of the C Runtime library.  Or if one of the SMO packages will install it on the target machine.  This is our current point of investigation.
    Thursday, October 30, 2008 10:24 PM
  • So indeed the SMO 10 redist packages install the msvcr80.dll version 8.0.50727.1833, so then we should not have any library or sxs errors if we install SMO by embedding the redist msi files in our installer.

    Of course the next obvious question is the cleanest ("proper") way to determine from inside the installer whether these packages have already been installed.  There is no sense in making a customer with, say, SQL Server 2008 installed on the target machine, wait while we (re)install 3 SMO packages that they already have.
    Thursday, October 30, 2008 11:01 PM
  • Hi all,

    I am adding this link for the sake of the 2000 other people reading this thread.  Smile


    It seems Visual Studio 2008 SP1 comes with SMO 10, so if you upgrade your VS you may run into some of the problems we have been exploring here.

    This link suggests using a Setup Wizard as one of the ways to deal with the deployment problems we are having, although I have not tried this approach (yet) because we don't really want to add a Setup Wizard to our project.
    Thursday, October 30, 2008 11:45 PM
  • Here are a couple ideas for checking for SMO: http://www.sqlmag.com/Article/ArticleID/93228/sql_server_93228.html
    Friday, October 31, 2008 12:37 AM
  • I'm not a setup guy but i think you still want to "install" the MSI. This will actually just up the ref count of the installed bits so if somebody then un-installs the client tools, or whatever else put SMO on the box, the bits get left on the box until the last application is removed.

    Friday, October 31, 2008 12:55 AM
    Answerer
  • You can get 9.0 SMO that connects to SQL Server 2008 by installing SQL Server 2005 SP2 Cumulative Update 5 (or later). Get it from here: http://support.microsoft.com/kb/943656

     

    Thanks,

    Sravanthi

     

    Wednesday, November 5, 2008 12:12 PM
  • Sravanthi,  thank you for this information.  I had imagined 9.0 SMO for SQL Server 2008 would not be available until the end of the year.  It is good to know where people can find it now.
    Wednesday, November 5, 2008 10:31 PM
  • Thank you very much to Papy Normand, Bruce Prang, and Sravanthi for the time you all took to help us investigate and solve our problems with updating our product to work with both SQL Server 2005 and SQL Server 2008.

    In the end, we took the approach of bundling the SMO 10 MSIs (Shared Management Objects, CLR Types, Native Client) in our product's installer and treating the libraries (and therefore Windows Installer 4.5 as well) as prerequisites. We needed to be able to install these libraries in order to support remote 2008 servers, and decided that if we always require them then we can simplify our maintenance by linking against only one version of SMO. This also avoids any need to manually load the SMO libraries at runtime. We install the appropriate platform where necessary, however we currently install English packages regardless of whether our main product is localized. So far so good in testing, but please let me know if you read this and think "oh no, you can't rely on always installing the English packages".

    It seems very simple when I describe the solution now, but when we were in the middle of the problem the error messages we encountered and the information we received seemed very confusing. I certainly learned a lot about the joys and the headaches of Windows deployment in the meantime!

    It is nice to know now that there is an update for SMO 9 supporting SQL Server 2008, however we are already into a QA cycle using the SMO 10 solution.

    Thank you again to everyone who took the time to help us out, and I hope this thread saves some other developers from similar headaches! Smile

    Wednesday, November 5, 2008 10:43 PM
  • Hello,

    I had exactly the same problem, but in my case installing MSIs on the target machine is impossible.
    Application using SMO 10 is working well on my dev machine (where all MSIs are installed) and on virtual machine with clean win xp, sql server 2005 express and .net 3.5 sp1. It didn't work on the test server with win 2003, sql server 2005 express and .net 3.5 (non-sp1).
    According to my event log, Microsoft.SqlServer.BatchParser is using some specific version of "Microsoft.VC80.CRT" COM assembly, which was not installed on the test server.
    Installing service pack 1 for .net 3.5 appears to solve this problem - I can run the application with SMO asemblies copied to the bin directory.
    Installing this: http://www.microsoft.com/downloads/details.aspx?familyid=200B2FD9-AE1A-4A14-984D-389C36F85647&displaylang=en should also solve it, but I haven't tried it. Installing SP1 is a good idea anyway.
    I hope it will help anybody.
    Friday, December 12, 2008 1:36 PM