Minimum Requirements to issue an XMLA Command to analysis services

What are the minimum requirements (in terms of referenced assemblies) I need in .NET programming to issue and xmla command to the analysis services?

What we want to do?

We want to create and SSDS .NET Stored Procedure which inserts a value in an SSAS Dimension Table and then in the same procedure issue an SSAS XMLA Process ADD Command.

It must be an SQL Procedure because auf external requirements

The Issue

IF we reference the Namespaces "Microsoft.AnalysisServices" and "Microsoft.AnalysisServices.XMLA" we receive errors

CREATE ASSEMBLY failed because method "add_CollectionChanging" on type "Microsoft.AnalysisServices.ModelComponentCollection" in external_access assembly "Microsoft.AnalysisServices" has a synchronized attribute. Explicit synchronization is not allowed in external_access assemblies.

We are only able to allow EXTERNAL_ACCESS on the SQL Server but no UNSAFE Assemplies.

Therefor the question - what is the minimum possibility to issue an XMLA Command?

- what is the SQL Agent Job Step Analysis Services Command using?

- Could XMLA Commandes be executed through an Analysis Services 9.0 OLEDB Connection (by OLEDB Command)?

- Without AMO?

Thankes for your Help

HANNES

Microsoft.AnalysisServices.AdomdClient is another option for sending XMLA commands, but it also does not support partially trusted callers so you'll get the same error. Any assembly that allows you to execute arbitrary XMLA commands should require special code access permissions (or simply be marked as unsafe) since XMLA commands can change data or reviel sensitive data and thus have the potential to be dangerous for untrusted code running under a trusted user account.

What you can do is write your own assembly which uses one of these other assemblies to send the XMLA command and mark it as supporting partially trusted callers. You'll need to be very careful if you do this and limit the capabilities of this new assembly so that it cannot be used in any harmful way (since code you don't completely trust can run it.) This means it should not execute arbitrary XMLA commands or connect to arbirtrary sources. You'll need to read up on code access security if you go this route - both to get it to work and make sure you don't introduce a security weekness into your system. If you accept any parameters into the methods, also be sure you protect against XMLA injection (like SQL injection but for XMLA). This solution can work, but use extreme caution since it affects the security of your system.