Wednesday, June 01, 2011 12:04 AMTrying to build a VS2010 project in a 32-bit Windows 7 environment. This project targets .NET 2 and uses SMO. I have CLR Types, Native Client and Management Objects installed from the SQL Server 2008 R2 Feature pack (from here http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=ceb4346f-657f-4d28-83f5-aae0c5c83d52) in this environment.
This project was being developed in a 32-bit Windows XP environment and it all compiled fine.
Now in the Windows 7 environment when I compile I get compilation errors...
The type or namespace name 'Table' could not be found (are you missing a using directive or an assembly reference?) The type or namespace name 'Database' could not be found (are you missing a using directive or an assembly reference?) The type or namespace name 'Server' could not be found (are you missing a using directive or an assembly reference?)
I have Microsoft.SqlServer.ConnectionInfo, Microsoft.SqlServer.Management.Sdk.Sfc, Microsoft.SqServer.Smo and Microsoft.SqlServer.SqlEnum referenced in my project references. These have the "Copy Local" property set to "True". If I remove one of the references and add it again the errors go away in the designer. I can see and access the classes in Microsoft.SqlServer.Smo successfully. It's only when I try to compile the project the code completion fails and in the editor it won't recognise these classes. When I use the object browser I can only see the enums in the SMO assembly.
This does not occur in the Windows XP development environment even tho' the same version of SMO is installed.
I thought it could be a missing dependancy so I tried to add additional assemblies from C:\Program Files\Microsoft SQL Server\100\SDK\Assemblies. This did not cure it either. In fact I received errors about some of the assemblies requiring a later version of the .NET framework than the one specified in the project (e.g. Microsoft.SqlServer.Management.Dac.dll).
I came across this posting which seems to be similiar (except the poster is targeting .NET 4)... http://stackoverflow.com/questions/4512176/visual-studio-2010-are-you-missing-a-using-directive-or-an-assembly-reference
Has anyone ever struck this or got any ideas around it?
Wednesday, June 01, 2011 2:49 AM
Wednesday, June 01, 2011 11:58 PM
Not quite sure what you are pointing me at here.
I have targeted the project as .NET Framework 2.0. Are the SMO assemblies only for a later version of .NET? How do I know?
My 32-bit Windows 7 development machine (actually a VM) has 1.0, 1.1, 2.0 SP2, 3.0 SP2, 3.5 SP1, 4.0 Client and 4.0 Full versions of the framework installed.
If I target 2.0, should be able to reference SMO? I had to browse specifically for the DLLs down in C:\Program Files\Microsoft SQL Server\100\SDK\Assemblies.
Thanks for any help.
Monday, August 08, 2011 11:15 PM
Finally got back to this and I think I might have stubbled upon a solution/work-around.
If I change the reference property "Specific Version" to "False" for Microsoft.SqlServer.ConnectionInfo, Microsoft.SqlServer.Management.Sdk.Sfc, Microsoft.SqServer.Smo and Microsoft.SqlServer.SqlEnum in my project references I can successfully compile. This was set to "True".
The help for the "Specific Version" property says "Indicates whether this assembly can be resolved without regard to multi-targeting rules for assembly resolution."
I'm assuming setting to "False" means it does take multi-targting rules into account when performing assembly resolution.
My project now compiles and appears to run ok although I haven't tested the SMO calls very thoroughly yet.
Hope this might help anyone else who comes across it.
Wednesday, August 10, 2011 10:39 PMModerator
Not so surprising solution, but i would be interested by the results of your tests.
Another possibility which could work is to copy the SMO dll in your project.Your executable is bigger but ( if my memory is not too bad ) it suppresses the problem ( according a test done in 2010 )
We are waiting for your feedback
Have a nice day
Mark Post as helpful if it provides any help.Otherwise,leave it as it is.