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.
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];
In Visual C++ 2010 i added a reference from a C++/CLI DLL (ControlWrapper.dll) to another C++/CLI DLL (CliLibrary.dll).
Both are including afxwinforms.h in the stdafx.h.
When i try to compile i get these errors:
error C2011: 'Microsoft::VisualC::MFC::CWin32Window' : 'class' type redefinition
error C2011: 'Microsoft::VisualC::MFC::CWinFormsEventsHelper' : 'class' type redefinition
If i turn of the Option Reference Assembly Output and add #using "CliLibrary.dll" to the using .cpp File i get the following warnings:
1>ControlWrapper.dll : warning C4944: 'CWin32Window' : cannot import symbol from 'c:\dev\trunk\CliLibrary.dll': as 'Microsoft::VisualC::MFC::CWin32Window' already exists in the current scope
1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxwinforms.h(83) : see declaration of 'Microsoft::VisualC::MFC::CWin32Window'
1> This diagnostic occurred while importing type 'Microsoft.VisualC.MFC.CWin32Window' from assembly 'CliLibrary, Version=1.0.4843.17337, Culture=neutral, PublicKeyToken=null'.
1>ControlWrapper.dll : warning C4944: 'CWinFormsEventsHelper' : cannot import symbol from 'c:\dev\sfirm\trunk\sfclrlib\debug\sfclrlib.dll': as 'Microsoft::VisualC::MFC::CWinFormsEventsHelper' already exists in the current scope
1> C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxwinforms.h(122) : see declaration of 'Microsoft::VisualC::MFC::CWinFormsEventsHelper'
1> This diagnostic occurred while importing type 'Microsoft.VisualC.MFC.CWinFormsEventsHelper' from assembly 'CliLibrary, Version=1.0.4843.17337, Culture=neutral, PublicKeyToken=null'.
How could i solve the error?
Well, this is a painful problem. It certainly explains why you are the first programmer I ever encountered that actually uses this. The problem is caused by this declaration in afxwinforms.h:
public ref class CWin32Window : public System::Windows::Forms::IWin32Window
// etc..
The public keyword is the killer, that adds the class to the manifest of your assembly. So when you reference it in another project that also includes the header then there are two definitions of the class. The mix of both native and managed classes in that header prevents a clean solution.
I think you already found the best solution, using the #include, with #pragma comment(disable:4944) to shutup the compiler. Including the header inside a namespace might be another viable hack, it renames the namespace of CWin32Window, but I'd expect trouble when linking mfcm90.lib. Restructuring your solution and keeping all winforms code inside one project is the only thing I can recommend.
Are you using the types in afxwinforms.h?
If not (like in my case), the solution is to comment the include and add this two lines:
#using <System.Windows.Forms.dll>
#using <System.Drawing.dll>
or add a reference to that two assemblies in your Project.
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’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.
I am getting the following error :
Error 1 Reference.svcmap: Failed to generate code for the service reference 'ServiceReference'. Cannot import wsdl:portType Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.DataContractSerializerMessageContractImporter Error: Referenced type 'KWI.CLUE.Auto.DataContracts.CLUEResult, KWI.CLUE.Auto.Contracts, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' with data contract name 'CLUEResult' in namespace 'http://schemas.datacontract.org/2004/07/KWI.CLUE.Auto.DataContracts' cannot be used since it does not match imported DataContract. Need to exclude this type from referenced types.
In order to resolve this issue : In the Configure Service Reference, clicked the Advanced button. Then chose "Reuse types in specified referenced assemblies". And unchecked KWI.CLUE.Auto.Contracts.
Now it works fine but when I am trying to access the client as below :
ServiceReference.CPServiceClient clueProcessingClient = new ServiceReference.CPServiceClient();
I am not able to see the methods of KWI.CLUE.Auto.Contracts. which is the correct behaviour.
Now is there another way to resolve this issue other than what I did.
Thanks in advance
BB