I’m trying to open a data base on embed vb code. On the MyConnection.Open() I get a error saying
Warning 1 [rsRuntimeErrorInExpression] The Value expression for the
textrun ‘Textbox1.Paragraphs[0].TextRuns[0]’ contains an error:
Request for the permission of type
'System.Data.SqlClient.SqlClientPermission, System.Data,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
failed. C:\Users\tedpottel\Documents\Visual Studio
My datasource in the report is Data Source=(local);Initial Catalog=bw
vb code is:
Public Function TestData () As Boolean
Dim MyConnection As System.Data.SQLClient.SqlConnection
Dim MyCommand As System.Data.SQLClient.SqlCommand
MyConnection = New System.Data.SQLClient.SqlConnection("server=(local);Initial Catalog=bw")
MyConnection.Open()
MyConnection.Close()
return True
End Function
First result on Google for "System.Data.SqlClient.SqlClientPermission":
Hi Joost,
Based on your description, this issue was probably related to the Code Access Security. Please refer to the following articles to configure the assembly to make sure it is set to fulltrust. Request for the permission of type 'SecurityPermission' failed:
http://blogs.msdn.com/b/floditt/archive/2009/08/10/request-for-the-permission-of-type-securitypermission-failed.aspx
Follow the link for information on how to configure your code to run at full trust.
The tool CasPol.exe (part of the .Net SDK) will help you to identify the CodeGroup that the System.Security assembly belongs to. In the GAC folder of this assembly I did a CasPol –rsg (resolvesGroup) on this assembly:
Now we can see that this assembly belongs to the Microsoft_Strong_Name (line 3 in the CodeGroup excerpt) and is configured for FullTrust. With the –rsp (resolvesPermissions) you can visualize all permissions that are granted to this assembly (as defined in the FullTrust named PermissionSet):
When the exception was raised, this assembly was configured to ‘Nothing’ (line 3 of the NamedPermissionSets excerpt). The problem was resolved by granting this assembly FullTrust.
Related
I am very new to working with Assemblies CLR in SQL Server
I have a database that has many of them
Is it possible to find out the original path that was used to load the assembly ?
Considering this is the way the assemblies are created I need that "from" path
CREATE ASSEMBLY ClassLibrary1
from 'D:\DotNetTeam\SQLServer\ClassLibrary1.dll'
I'm asking this because this assembly : a798b6eb4255719355458f3749073dc1b is not found on the server list and is being reported as unsecure (I know I have to sign it, but for that I need to first find it)
I found this other question but is not what I need.
How to find the assembly registered in SQL Server?
UPDATE
Querying the sys.assembly_files table, I notice that the record exists there but not on the left side (Object Explorer: Assemblies), do I need to re-created the assembly ?
select *
from sys.assembly_files
where name like 'a79%'
The solution for this question might also help you solve any of these
errors:
System.IO.FileLoadException: Could not load file or assembly
'ASSEMBLY_NAME, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
or one of its dependencies. An error relating to security occurred.
(Exception from HRESULT: 0x8013150A)
System.IO.FileLoadException: Could not load file or assembly
'ASSEMBLY_NAME, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
or one of its dependencies. Exception from HRESULT: 0x80FC80F1
Yes, but only if the assembly was loaded from a DLL on the file system and not by supplying the VARBINARY literal / hex bytes. When loaded from an external DLL (a method that I strongly recommend against, btw), the original path is stored in the [name] column in sys.assembly_files.
Execute the following to show any potential paths:
-- Change this to the assembly name or path to apply filter:
DECLARE #AssemblyName NVARCHAR(260) = '';
-- The content can be used to export the DLL:
SELECT asm.[name] AS [Assembly],
afl.[name] AS [PathOrAltName],
asm.[permission_set_desc],
afl.[file_id],
afl.[content]
FROM sys.assembly_files afl
INNER JOIN sys.assemblies asm
ON asm.[assembly_id] = afl.[assembly_id]
WHERE asm.[name] LIKE N'%' + #AssemblyName + N'%'
OR afl.[name] LIKE N'%' + #AssemblyName + N'%'
ORDER BY asm.[name], afl.[file_id];
If the assembly was loaded from a VARBINARY literal / hex bytes (i.e. 0x4D5A9000...), then the [name] column in sys.assembly_files should be the same as the [name] column in sys.assemblies (which is the name used in the CREATE ASSEMBLY statement).
Querying the sys.assembly_files table, I notice that the record exists there but not on the left side
To be clear, both screen shots in the question clearly show a long list of very poorly (and clearly programmatically) named assemblies. And it is not possible, in any way, for an entry to show up in sys.assembly_files (or any of the other assembly-related management views) without it existing in sys.assemblies.
ALSO: are you certain that you are in the same database in the query window that you are drilling-down into in Object Explorer?
they only provided me a database backup
Assemblies physically exist in each DB where CREATE ASSEMBLY was executed and show up in sys.assemblies, sys.asssembly_files, and a few other system catalog views. This is one of many benefits of SQLCLR: the assembly is not external to the DB as is the case with the now deprecated external stored procedure API / feature (i.e. XPs).
I know I have to sign it...
So then I assume you are restoring a pre-SQL Server 2017 DB into SQL Server 2017 or newer. In this case you do need to sign all unsigned assemblies, BUT you do not need to export them in order to do this (an extremely common misunderstanding due to Microsoft misunderstanding the issue themselves and hence providing incorrect documentation on this topic). This is rather simple to solve given that you can sign the assembly in-place in order to get past the new "CLR strict security" debacle:
SQLCLR vs. SQL Server 2017, Part 4: “Trusted Assemblies” – The Disappointment (Msg 10314)
Here is a summary of the steps:
Create Certificate (using a password) in the DB containing the assembly / assemblies using CREATE CERTIFICATE ...
Sign the Assembly using ADD SIGNATURE TO Assembly::[{assembly_name}] ...
Copy the Certificate to [master] (but not the Private Key!)
Create a Login from the Certificate
Grant the signature-based Login the UNSAFE ASSEMBLY permission
You will still need to make sure that each assembly has the correct PERMISSION_SET for what it needs to do
Here is the demo script from that article that you can copy and adjust to fit your needs:
Avoiding "Trusted Assemblies" - Demo (on PasteBin)
For more information on working with SQLCLR in general, please visit: SQLCLR Info
UPDATE (from O.P.):
The issue was that the name of the assembly was ComputeHashFuncAssmembly but the path was the one that contained a798b6eb4255719355458f3749073dc1b so an ALTER ASSEMBLY was needed. That was also the reason it was not visible on the left side because it was under ComputeHashFuncAssmembly and not as the hex code.
I exported the assembly because the original DLL was not provided to me and I wanted to have it.
These are the steps for signing the assembly
USE [yourDatabase];
GO
CREATE CERTIFICATE [AssemblyCertificate]
ENCRYPTION BY PASSWORD = 'aPasswordYouChoose'
WITH SUBJECT = 'Assembly Certificate';
ADD SIGNATURE TO Assembly::[ComputeHashFuncAssmembly]
BY CERTIFICATE [AssemblyCertificate]
WITH PASSWORD = 'aPasswordYouChoose';
ALTER ASSEMBLY ComputeHashFuncAssmembly
WITH PERMISSION_SET = SAFE;
-- Copy the certificate to the master
BACKUP CERTIFICATE [AssemblyCertificate] TO FILE = 'C:\temp\certificate.cer';
USE [master];
GO
-- DROP certificate [AssemblyCertificate];
CREATE CERTIFICATE [AssemblyCertificate]
FROM FILE ='C:\temp\certificate.cer';
CREATE LOGIN [login_AssemblyCertificate]
FROM CERTIFICATE [AssemblyCertificate];
GRANT UNSAFE ASSEMBLY TO [login_AssemblyCertificate];
I am trying to call Kentico API from LINQPad, but getting the following exception:
[AbstractProvider.GetProvider]: The object type 'cms.document' is missing the provider type configuration
My code is:
void Main()
{
var pages = DocumentHelper.GetDocuments("CMS.MenuItem").Path("/", PathTypeEnum.Children);
pages.Dump();
}
Note: I tested the code from Visual Studio, it works, but not from LINQPad.
The problem is that during the initial discovery Kentico looks only at the following paths:
AppDomain.CurrentDomain.BaseDirectory
AppDomain.CurrentDomain.RelativeSearchPath
Which in case of LINQPad are C:\Program Files (x86)\LINQPad4\ and null. Therefore the providers do not get resolved.
I've tried running the code in a new AppDomain but it doesn't seem to work in LINQPad. I suggest submitting this to Kentico as an idea or an issue.
A workaround to this would be copying the LINQPad executable to a location of Kentico DLLs - e.g. C:\inetpub\wwwroot\Kentico82\Lib. That works just fine.
Update (thx to Joe Albahari):
If you wrap your code in this:
var appDomain = Util.CreateAppDomain ("AD", null, new AppDomainSetup
{
PrivateBinPath = #"C:\inetpub\wwwroot\Kentico82\CMS\bin",
});
appDomain.DoCallBack(() => { /* your code */ });
you'll be able to execute it. However, you can't Dump() it to the output window. But you can write it to a text file for example. If you experience the following error:
FileNotFoundException: Could not load file or assembly 'LINQPad, Version=1.0.0.0, Culture=neutral, PublicKeyToken=21353812cd2a2db5' or one of its dependencies. The system cannot find the file specified.
Go to Edit -> Preferences -> Advanced -> Run each query in its own process and turn it off.
After converting VB 2008 project to VB 2012, how to fix the error regarding the MSFlexGridLib, The error says:
Reference required to assembly 'Interop.MSFlexGridLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' containing the type 'MSFlexGridLib.AllowUserResizeSetting'. Add one to your project
The blue line for error occured on the '.AllowUserResizing'
.AllowUserResizing = MSFlexGridLib.AllowUserResizeSettings.flexResizeColumns
Go to your project's properties, select add reference, in COM find Microsoft FlexGrid Control and select it to add it as reference.
I am creating an SSIS package programatically in vb.net version 4.0 for SQL server 2008 R2 and I am having difficulty creating an Execute SQL Task. The code for the task is as follows:
Public Sub CreateExecuteSQLTask()
Dim TaskHost = DirectCast(Package.Executables.Add("Microsoft.SqlServer.Dts.Tasks.ExecuteSQLTask.ExecuteSQLTask, Microsoft.SqlServer.SQLTask, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91"), Microsoft.SqlServer.Dts.Runtime.TaskHost)
TaskHost.Name = "Task"
TaskHost.Description = "Task Description"
Dim ExecuteSQLTask As Dts.Tasks.ExecuteSQLTask.ExecuteSQLTask
ExecuteSQLTask = DirectCast(TaskHost.InnerObject, ExecuteSQLTask)
ExecuteSQLTask.Connection = DestinationDBConnectionManager.ID
ExecuteSQLTask.SqlStatementSource = "Select * from Employees"
End Sub
When the above code runs I get the following exception when casting the TaskHost to an Execute SQL command.
Unable to cast COM object of type 'System.__ComObject' to class type 'Microsoft.SqlServer.Dts.Tasks.ExecuteSQLTask.ExecuteSQLTask'. Instances of types that represent COM components cannot be cast to types that do not represent COM components; however they can be cast to interfaces as long as the underlying COM component supports QueryInterface calls for the IID of the interface.
I have used the following article as a reference:
Creating Packages in code
Please advise how I can get past this issue.
I managed to work out the problem.
Dim ExecuteSQLTask As Dts.Tasks.ExecuteSQLTask.ExecuteSQLTask
needs to be changed to
Dim ExecuteSQLTask As Dts.Tasks.ExecuteSQLTask.IExecuteSQLTask
As the exception suggested, the COM component can be cast to an interfaces. In the above case, i was casting the COM component to the ExecuteSQLTask class rather than the interface.
I found that casting the COM component is a lot easier than setting the SQL task's properties through XML.
Your problem is .Net 4.0. Or, more specifically, the ExecuteSQLTask assembly code has something in it that makes it incompatible with .Net 4.0. So just add the following lines to your app.config file:
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
<runtime>
<NetFx40_LegacySecurityPolicy enabled="true"/>
</runtime>
And it'll work. No, I have no idea why.
I have some third party assembly which was build using Net 2.0. Although I can of course reference that assembly in net 4, running the app results in all kinds of strange errors.
So I though loading it in a separate application domain will fix the problem but it does not. I assume it is still executed using the Net 4 runtime. Is there any way to force execution of an application domain in a different net version ?
I use CreateInstanceFromAndUnwrap and than call the proxy.
Thanks for any help
Joe
You can use the supportedRuntime configuration element to set the CLR version of an AppDomain. If you do not want to add this to your app.config, you can add a second .config file that will be used during the construction of the new AppDomain. Have a look at AppDomainSetup.ConfigurationFile for more info.
Create AppDomain. And Create DomainManager:MarshalByRef object in new domain.
DomainManager Load Assembly To created(new) domain.
AppDomainSetup ads = new AppDomainSetup();
AppDomain managerAD = AppDomain.CreateDomain("AD1", null, ads);
Assembly asm = managerAD.Load(typeof(DomainManager).Assembly.FullName);
string typeName = typeof(DomainManager).FullName;
DomainManager manager = (DomainManager)managerAD.CreateInstanceAndUnwrap(asm.GetName().Name,
typeName);
public class DomainManager : MarshalByRefObject
{
public void GetAppDomain(string assemblyFileName)
{
Assembly asm2 = Assembly.LoadFrom(assemblyFileName);
Type neededType = asm2.GetType(<paste type>);
object instance = Activator.CreateInstance(procType);
}