0

I created a WCF procedure that employs a company internal web service that comes with a whole bunch of assemblies to be deployed. That worked fine on my local 2008 R2 32-bit so far.

When trying to deploy the involved assemblies on a SQL Server 2008 (not R2) 64-bit like this:

ALTER DATABASE sqlclr SET TRUSTWORTHY ON 

CREATE ASSEMBLY [Common.LargeSetPersistence]
FROM G:\CRTS\DataService\DataService.QueryBrowser\Common.LargeSetPersistence.dll'
WITH PERMISSION_SET = UNSAFE;

This works so far, but the next attempt:

CREATE ASSEMBLY [DataService.Client.WCF]
FROM 'G:\CRTS\CRP\DS_to_DB\DataService.Client.WCF.dll'
WITH PERMISSION_SET = UNSAFE

results in the following error:

Msg 10300, Level 16, State 2, Line 1
Assembly 'DataService.Client.Core' references assembly 'common.largesetpersistence, 
version=0.0.0.0, culture=neutral, publickeytoken=null.', which is not present in the 
current database. SQL Server attempted to locate and automatically load the referenced 
assembly from the same location where referring assembly came from, but that operation 
has failed (reason: version, culture or public key mismatch). Please load the referenced 
assembly into the current database and retry your request.

The required assembly has just been successfully installed though?! Also the version=0.0.0.0 seems a little bit odd to me.

All the assemblies have been built with Any CPU flag, so it should not be a 32/64-bit issue.

Any help is appreciated.

Shiva
  • 20,575
  • 14
  • 82
  • 112
Prefect73
  • 321
  • 3
  • 14

2 Answers2

0

Just a tip to get you started: make a new from scratch DLL with 'hello world' level simplicity. Install that and double check that your SSMS is running on the actual machine where the DLL is. If you use "G:", SSMS will assume it is on the machine that SSMS is running on.

Good luck. Also double check your perms.

daviesdoesit
  • 805
  • 9
  • 14
  • strange enough, other DLLs could be loaded from the same location. But i will try to copy them all to local C: and try again. Unfortunately it´s a hosted server with scheduled change windows, so i have to wait some time :( – Prefect73 Feb 14 '14 at 08:39
  • having all the DLLs on local drive C: made no difference, it is still complaining about a missing assembly that´s actually present – Prefect73 Feb 25 '14 at 08:10
0

I would check if the Profile that SQL Server is running under (usually 'Network Service') has proper permissions to that folder? It's easy to forget that the query you are running is not necessarily being run under your personal credentials.

James
  • 330
  • 1
  • 12
  • several other DLLs were successfully installed from the same folder, so i don´t think it´s about permission – Prefect73 Feb 14 '14 at 08:34