furmangg


If I compile a simple .NET DLL with the following function and register it as an assembly in Analysis Services:

public static int MyFunction(object o) {
return 99;
}

When I run the following query I get an error which reads "Execution of the managed stored procedure failed with the following error: Cross assembly or cross domain calls not supported!. Execution of the managed stored procedure failed with the following error: Cross assembly or cross domain calls not supported!. Execution of the managed stored procedure CSng failed with the following error: Microsoft::AnalysisServices::AdomdServer::AdomdException."

with member test as MyAssembly.MyFunction(CSng("2.5555"))
select test on
0
from [adventure works]

Is there any way around this I believe this problem is occurring because CSng is coming from the VBA library which evidently isn't loaded in the same app domain as MyAssembly within Analysis Services.

I know I could workaround this issue by changing the MDX or by building my own CSng function and compiling it into MyAssembly. But the problem behind this question is such that I can't change the MDX. For instance, Report Builder calculations can use VBA functions which might cause the error seen above if I use .NET sprocs in the calc script.





Re: Cross assembly or cross domain calls not supported

Mosha Pasumansky


I think the problem here might be related to the data type of the argument passed to the function. What if you define it as scalar data type instead of object





Re: Cross assembly or cross domain calls not supported

furmangg

Changing the signature of the C# function to use int, float, double, or decimal doesn't fix the problem.

The only other oddity I would mention is that most, but not all VBA functions cause this error. For instance, the Abs, Round, Now, Right, Left, Mid, Len, IsError, IsArray, and Int VBA functions do not cause an error. (Those are the only ones, I think.) Any idea why

with member test as MyAssembly.MyFunction(VBA.Abs(-1))
select test on 0
from [adventure works]

I'm guessing that the VBAMDX and the System assemblies are loaded into a different app domain than assemblies that users register. Is that the case Is that why we're getting the error Are some

The server level assembly VBAMDX is a .NET DLL:
C:\Program Files\Microsoft SQL Server\MSSQL.2\OLAP\bin\msmdvbanet.dll

But there's also a VBAMDXINTERNAL assembly that I don't understand. It's a COM DLL supposedly, but the Source property which usually shows the path to the COM DLL is blank on it. Does a blank Source for a COM DLL tell SSAS to do something special like use mdmdsrv.exe or something A little explanation of this might trigger a bright idea from somebody on a way to get around this cross domain error.







Re: Cross assembly or cross domain calls not supported

Mosha Pasumansky

> For instance, the Abs, Round, Now, Right, Left, Mid, Len, IsError, IsArray, and Int VBA functions do not cause an error. (Those are the only ones, I think.) Any idea why

That's because they only look like VBA functions, but in fact are implemented internally as builtin functions.

> I'm guessing that the VBAMDX and the System assemblies are loaded into a different app domain than assemblies that users register. Is that the case Is that why we're getting the error

Yes, they are loaded into different app domain, but I still don't understand why there is a problem. The VBA functions should've been computed before the sproc is called, and just pass the result to it, so it is not clear to me why the error happens. I may need to look deeper into it.






Re: Cross assembly or cross domain calls not supported

Darren Gosbell

Mosha Pasumansky wrote:

The VBA functions should've been computed before the sproc is called, and just pass the result to it, so it is not clear to me why the error happens. I may need to look deeper into it.

This is what I would have thought too. I tried changing setting up a function with a different signature and even tried implementing CSng() in my own assembly, but that only worked if you called MyAssembly.MyFunc(MyAssembly.CSng("2.5555")), which is pointless as the desired effect was to have the assembly handle being passed an argument that was calculated by a function in another assembly. It's almost like "MyAssembly" is being passed a function pointer or delegate instead of the result from CSng().

furmangg - I noticed you have logged the issue on connect https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx FeedbackID=249956 - I have added my vote.






Re: Cross assembly or cross domain calls not supported

Irina Gorbach

I have invistigated this kind of problem before, and unfortunatly can't provide good news, except explanation why this problem happens. As you know, we execute assembly in a separate app domain, but we remote to the app domain not only for actual execution of the function, but a bit earlier - prior to evaluation of the function's parameters. Therefore, evaluation of the parameter CSng("2.5555") happens in the appdomain for MyAssembly and AS tries to create another AppDomain for VBA. If both functions implemented in the same assembly, same appdomain will be used, which explains why MyAssembly.MyFunc(MyAssembly.CSng("2.5555")) works.




Re: Cross assembly or cross domain calls not supported

Darren Gosbell

Thanks for letting us know Irina, this is pretty much what it "felt" like, but it's nice to know that it's not anything that we are doing wrong.




Re: Cross assembly or cross domain calls not supported

furmangg

FYI, Irina has created a word doc listing all the VBA functions and noting which are implemented as "internal" functions. Very helpful reference:

http://www.e-tservice.com/downloads.html

Then download the VBA functions in Analysis Services 2005 doc which is:
http://www.e-tservice.com/Files/vba_functions_in_as2005.doc






Re: Cross assembly or cross domain calls not supported

Andrew Garbuzov

Can you use COM assemblies for some of your functions You could create them with .NET code and i think this should work. If your function is simple and does not consume AdomdServer object model then you should be fine. The assembly will be loaded into some (presumably default) domain. The admin will have to trust your code. If performance is a concern then ATL with C++ is better for COM assemblies than C# but this might be not an issue for your perf targets.



Re: Cross assembly or cross domain calls not supported

furmangg

Andrew Garbuzov wrote:
Can you use COM assemblies for some of your functions You could create them with .NET code and i think this should work. If your function is simple and does not consume AdomdServer object model then you should be fine. The assembly will be loaded into some (presumably default) domain. The admin will have to trust your code. If performance is a concern then ATL with C++ is better for COM assemblies than C# but this might be not an issue for your perf targets.

Andrew, thanks for your comments. I believe that a COM assembly would not suffer from the same error. So that might be a good route to go, although, as you point out, in doing that you lose access to the AdomdServer API and have to be content to just deal with simple scalar values as parameters and return values.

As for whether you can write that in C#, I know it is possible to mark a class so it can be visible to COM using the [ClassInterface(ClassInterfaceType.AutoDual)] or similar. I was able to compile a .NET DLL that VB6 could see, but when I registered that DLL as a COM DLL in Analysis Services, I couldn't call any of the functions. If you know any secret tricks to get this to work, please do post back.

I know I could write the DLL in VB6 (or ATL with C++) and it would work. But I'm not too wild about doing that.






Re: Cross assembly or cross domain calls not supported

Andrew Garbuzov

Did you register your Dll as a COM server You probably need to find some article about building COM servers with C#. A quick search gives this article - http://www.csharphelp.com/archives/archive281.html.

As for building it for VB6. Please make sure your COM object supports either Free threaded apartment or Both. I do not remember, but VB6 might be limited to building only Apartment objects.

Anyway, if you really try COM way, i think you need just to try making it with ATL. There should be a wizard, which would create the skeleton very easy for you. You would just implement the code of the function.





Re: Cross assembly or cross domain calls not supported

furmangg

I believe my .NET DLL is registered as a COM server, but I still can't get Analysis Services to consume it. I've tried every combination of gacutil, regasm, and tlbexp that I could find but haven't had any luck yet. I will say that I don't understand the ugly details of COM, so I may be doing something stupid.