ssembly 'XXXX, version=0.0.0.0, culture=neutral, publickeytoken=null.' was not found in the SQL catalog.

Question

Post reply

ssembly 'XXXX, version=0.0.0.0, culture=neutral, publickeytoken=null.' was not found in the SQL catalog.

Shane N

Ten Centuries

Points: 1323
More actions
August 17, 2010 at 2:28 am

#227949

Error 2 Assembly 'wog.sql.shared, version=0.0.0.0, culture=neutral, publickeytoken=null.' was not found in the SQL catalog.

So I know I'm missing something simple 🙁

Everywhere I google about this it always deals with people trying to add assemblies outside the scope of the SQL CLR libraries but that's not what I'm trying to really do...

wog.sql.shared is a SQL CLR library that I'm able to deploy just fine

I have it referenced by my WOG.SQL project

when I deploy the WOG.SQL project the WOG.SQL.SHARED dll deploys fine but then the WOG.SQL project gives me this error about WOG.sql.shared not found in the SQL Catalog 🙁

Thanks in Advance

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply

Jonathan Kehayias One Orange Chip Points: 26778 More actions · Answer 1

Do they both show up in sys.assemblies?

select * from sys.assemblies

What other references are there in either of the assemblies?

Jonathan Kehayias One Orange Chip Points: 26778 More actions · Answer 2

The other thing to check is:

Did you deploy both assemblies to the same database? It would be pretty easy to deploy one of them to a different database and then end up with this kind of a problem.

Shane N Ten Centuries Points: 1323 More actions · Answer 3

Jonathan Kehayias (8/17/2010)

Do they both show up in sys.assemblies?

select * from sys.assemblies

What other references are there in either of the assemblies?

no only WOG.SQL.SHARED dll shows up because

it's in there and listed

WOG.SQL.Shared 1 65609 wog.sql.shared, version=0.0.0.0, culture=neutral, publickeytoken=null, processorarchitecture=x86

so I don't know why WOG.SQL can't find it

they don't reference anything else that exciting they are both set to SAFE and prior to including a WOG.SQL.SHARED dll with WOG.SQL WOG.SQL deployed just fine

Shane N Ten Centuries Points: 1323 More actions · Answer 4

Shane N

Ten Centuries

Points: 1323

August 17, 2010 at 9:40 am

#1207977

Jonathan Kehayias (8/17/2010)

The other thing to check is:

Did you deploy both assemblies to the same database? It would be pretty easy to deploy one of them to a different database and then end up with this kind of a problem.

yea it's the same DB

Shane N Ten Centuries Points: 1323 More actions · Answer 5

Jonathan Kehayias (8/17/2010)

The other thing to check is:

Did you deploy both assemblies to the same database? It would be pretty easy to deploy one of them to a different database and then end up with this kind of a problem.

I even tried just doing it as a script where it has it all in BINARY And you do CREATE Assembly

WOG.SQL.SHARED creates fine and WOG.SQL throws that error 🙁

Shane N Ten Centuries Points: 1323 More actions · Answer 6

Shane N

Ten Centuries

Points: 1323

August 17, 2010 at 11:12 am

#1208050

it looks like it's some environment issue I'm running W7 64 bit

and it works fine to deploy for a colleague on W7 32bit

I set all the targets to x86 which worked in the past just fine so I have no idea

Tonci Korsano Mr or Mrs. 500 Points: 571 More actions · Answer 7

hi there,

maybe your assembly is supposed to go inside "program files (x86)" folder.

maybe you need to build that assembly project, with visual studio, to target x64 environment in a separate compilation. moreover, you might be able to compile that assembly for x86 and x64 of one dotnet version, like 2.0.

it is only ideas from past experiences...

best regards,

tonci.

Shane N Ten Centuries Points: 1323 More actions · Answer 8

Tonci Korsano (8/17/2010)

hi there,

maybe your assembly is supposed to go inside "program files (x86)" folder.

maybe you need to build that assembly project, with visual studio, to target x64 environment in a separate compilation. moreover, you might be able to compile that assembly for x86 and x64 of one dotnet version, like 2.0.

it is only ideas from past experiences...

best regards,

tonci.

yea we're trying to deploy it as an x86 assembly which has worked in the past

And this is to a separate workstation that's windows 2003 server running SQL 2008

It's funny because if I have my colleague deploy the DLL's to the 2003 work station

then I have it generate create assembly scripts

then I run those scripts locally it creates all those assemblies just fine

it's only when trying to deploy from VS 2008 does it freak out and not work for me 🙁

I've tried every possible deployment configuration I can with targets and what not and nothing

Jonathan Kehayias One Orange Chip Points: 26778 More actions · Answer 9

I would begin to suspect something associated with UAC here, or the fact that you are targeting a x64 SQL Install with a x86 build of the DLL? I haven't really played around with that but will give it a whirl on my laptop VM's to see if I can reproduce this issue.

Shane N Ten Centuries Points: 1323 More actions · Answer 10

Shane N

Ten Centuries

Points: 1323

August 24, 2010 at 1:29 am

#1210819

I'm targeting an x86 installation of SQL Server on windows 2003 with an x86 build of the dll

I got a virtual machine of xp up and running and I've started deploying from that

that seems to work ok enough for now

the two dlls though I never got working