New dependency to Microsoft.SqlServer.Types have been introduced

Hi,

Two weeks ago, I upgraded my version of LightSpeed (Last version was += 2012/01). Then, I shipped a new version of my application which have a dependency to LightSpeed to my client and an error occurs. A dependency to the Microsoft.SqlSever.Types.dll. I shipped this dll found in my computer to the client and it fixed the problem.

Here is the error:

Could not load file or assembly 'Microsoft.SqlServer.Types, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.

Note that my customer don't have Sql Server installed or their machine.

Must I now ship this dll to each of my customers when I have a reference to LightSpeed?

Thank you.

Do you have the stack trace associated with that? That will help us in tracking down what is triggering this being loaded. Also presumably you are not actually using the SqlServer2008 provider (which does have a dependency on that assembly).

Jeremy

Hi Jeremy,

Sorry but we don't kept a backup of the error and now the customer is not able to reproduce.

The only message that I have in my log is:

Error: Could not load file or assembly 'Microsoft.SqlServer.Types, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.

The new DataProvider.SqlServer2008 have been added recently?

When you said that the provider for SqlServer2008 don't have any dependencies for Microsoft.SqlServer.Types, are you able to investiguate in which cases when we use SqlServer2005 provider, an error can occurs if the Microsoft librairies is not on the computer?

Sorry for not being able to help you more.

I continue to search on my side for more information...

Thank you.

I think a recent nightly picked up a dependency on Mono, too. I had to add a reference to one of the Mono DLLs you distribute. (A SQL Server project, not Postgres.)

@chadw: I certainly have not seen this, did you have to add a reference to the Postgres assembly as well or just Mono.Security? Do you have a feel for the time range when this changed?

Lastly any chance of a repro or some more details that might help track this down? We have certainly seen the need to have all the referenced assemblies available in situations where you run into some "scan all the dependancies from this assembly" kind of issue but nothing as specific as this.

Jeremy

Here's a stack trace, we're going to try to actually add this DLL to the same folder as the application that got this error. See if that helps.

System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.SqlServer.Types, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.SqlServer.Types, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91'
   at  . .ƒ(IdentifierExpression , FieldModel& ,  & , String& )
   at  . .ƒ(IdentifierExpression , FieldModel& , ToOneModel& ,  & , String& )
   at  . .ƒ(IdentifierExpression )
   at  . .ƒ(SelectStatement , Order , Boolean )
   at  . .ƒ(SelectStatement , Boolean ,   )
   at  ..ƒ(LightSpeedContext , List`1 , QueryExpression , Order , Group , String , Boolean , Boolean )
   at  . .ƒ(List`1 , Query , String , IdentifierExpression )
   at  . .ƒ(TypeModel , Query , IList )
   at  . .ƒ(Query , TypeModel , IList )
   at  . .ƒ(Query , IList )
   at Mindscape.LightSpeed.UnitOfWork.Find(Query query, IList results)
   at Mindscape.LightSpeed.UnitOfWorkBase.Find(Query query)
   at Mindscape.LightSpeed.Linq.Plan.SingleQueryPlan.ExecuteImmediate(IUnitOfWork unitOfWork, Type returnType)
   at Mindscape.LightSpeed.Linq.LinqQueryProvider.System.Linq.IQueryProvider.Execute[S](Expression expression)
   at System.Linq.Queryable.FirstOrDefault[TSource](IQueryable`1 source)

Update to a recent nightly build - we believe this was an issue that has now been resolved. See: http://www.mindscapehq.com/forums/thread/352574 for details.

Jeremy