June 30, 2011 at 9:14 am
Hi everyone, i'm trying to call a .net assembly that wraps a few COM calls (to a third party dll) from Sql Server. The assembly registers fine (i tried registering with unsafe and external access), but when i run the procedure i get this error:
A .NET Framework error occurred during execution of user-defined routine or aggregate "ManagedCodeCallTest": System.UriFormatException: Invalid URI: The URI is empty. System.UriFormatException: at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind) at System.Uri..ctor(String uriString) at System.ComponentModel.Design.RuntimeLicenseContext.GetLocalPath(String fileName) at System.ComponentModel.Design.RuntimeLicenseContext.GetSavedLicenseKey(Type type, Assembly resourceAssembly) at System.ComponentModel.LicenseManager.LicenseInteropHelper.GetCurrentContextInfo(Int32& fDesignTime, IntPtr& bstrKey, RuntimeTypeHandle rth) at ManagedCode.MyClass.ArielComponentCall()
Any ideas? Is what i'm trying to do even possible? I read something about licensed dlls but the information was very vague.
Thanks, Gonzalo
June 30, 2011 at 9:31 am
I'm thinking this is not possible:
http://social.msdn.microsoft.com/forums/en-US/sqlnetfx/thread/eaa2a257-e994-452b-855e-7d6841b15d42/%5B/url%5D
And you can look at this:
http://www.sqlservercentral.com/Forums/Topic208912-246-1.aspx
CEWII
June 30, 2011 at 9:36 am
Thank you for the answer Elliot, i had already seen both links. Unfortunately they don't seem to provide much clarification regarding my problem.
Thanks, Gonzalo
June 30, 2011 at 10:36 am
Sorry I couldn't help more but there are a fair number of restrictions tied to using SQLCLR..
CEWII
June 30, 2011 at 1:30 pm
Is this a 32 bit COM object trying to be run on a 64 bit server? For that matter, have you you compiled your .net assembly for 64 bit compatibility (or vice versa)?
The probability of survival is inversely proportional to the angle of arrival.
June 30, 2011 at 1:32 pm
Nope, it's 32 bits dll running in a 32 bits environment.
June 30, 2011 at 1:36 pm
Were you successfully able to instantiate the object in your development environment?
People use COM but I personally would try to avoid the use of COM in a production environment. COM is inefficient, usually not thread safe and registering and unregistering them is ugly. I would tray and replace the whole shebang with a .net assembly.... you'll be a lot better off.
The probability of survival is inversely proportional to the angle of arrival.
June 30, 2011 at 1:39 pm
I was able to use it from a .Net console project, yes.
I agree with you on trying to avoid COM, but unfortunately it's not an option in this case.
Thanks anyway for your help.
June 30, 2011 at 1:44 pm
Have you successfully run the DDL to create the assembly then create the User defined function/procedure/aggregate or whatever in your database (test or production?)
The probability of survival is inversely proportional to the angle of arrival.
June 30, 2011 at 1:45 pm
sturner (6/30/2011)
Is this a 32 bit COM object trying to be run on a 64 bit server? For that matter, have you you compiled your .net assembly for 64 bit compatibility (or vice versa)?
My experience shows that unless you explicitly chose an architecture the assembly will be able to run on either. However in the case of .net interops you are limited to the architecture of the COM library. to make matters worse, by and large you have to pull all the libraries into SQL except for a few which can be called directly, I don't think you can accomplish this with a COM library. The interop maybe but not the library that is used by the interop.
CEWII
June 30, 2011 at 1:47 pm
Yes, i created the assembly in my db server (it's a test environment) and the stored proc that references the assembly. The assembly creation worked fine, i get the error while calling the SP. Running the same code from a console app instead of SQL server works.
Viewing 11 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply