I'm using tlbimp to generate a .Net interop of a COM assembly. This COM assembly has a product version and file version like 7.X.X.X but when I'm using TlbImp, my interop has then a version like 1.Y.0.0. I'm aware I can change this version when I'm using TLBImp via parameters of the executed command lines but I'm wondering where this version comes from.
Can I access a manifest of this COM assembly?
Why I cannot see this version on the property of the file in the explorer?
I have different version of this assembly and I see the version generated always different but I'm failing to find where this version come from.
Thanks
I had a hunch that it was the version of the typelib. I took a test project that had a typelib of version 1.0 and ran tlbimp on it, and it produced an import assembly with file version of 1.0. I then changed the version of the typelib to 1.19, recompiled, and reran tlbimp. The file version of the new import assembly was 1.19 (well, 1.19.0.0).
Using OleView you can load the typelib of the EXE/DLL your using for tlbimp. Check the version of the typelibrary. Compare it to the file version of your import assembly. I bet they match.
Makes sense they'd want the version numbers to match.
I was setting up number of projects to build NuGet packages and push onto NuGet server, so it could be later used by Octopus Deploy.
All was fine until I needed to apply the same process to legacy projects. The error was:
error MSB4062: The "OctoPack.Tasks.CreateOctoPackPackage" task could not be loaded from the assembly ...\OctoPack.Tasks.dll. Could not load file or assembly 'file:///...\OctoPack.Tasks.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. Confirm that the declaration is correct, and that the assembly and all its dependencies are available.
Now I understand that OctoPack was not built for .Net 2.0, but just wonder if anyone hit/solved that problem.
Are you able to change the build target of the application from 2.0 to something more recent? If so, I would upgrade my app, rather than look for a downgraded version of Octopack.
Alternatively, you can use NuGet.exe to create packages rather than using OctoPack. I actually prefer OctoPack, but NuGet.exe wouldn't care about your .NET version.
I ended up amending the Octopack code to work with .Net 2.0 and MSBuild 2, which is successfully applied to all our .Net 2.0 and 3.5 applications being packaged on the CruiseControl server.
If someone is in a similar situation here is the amended code (forked from the original Octopack)
I downloaded Firebird ADO.NET Data Provider 3.0.2 from the Firdbird website.
http://www.firebirdsql.org/en/net-provider/
I start a new visual studio project, specifying .Net Framework 4 (not client profile)
At the top of one of my source files I put
using FirebirdSql.Data.FirebirdClient
Then I try to build the project, and it gives the following error -
The type or namespace name 'FirebirdSql' could not be found (are you missing a using directive or an assembly reference?)
However if I download version 2.6 of the Firebird ADO.NET Data Provider, it works just fine.
Am I understanding this correctly, version 3.0.2 does not support .NET Framework 4.0?
Unfortunately Windows Xp doesn't support .NET 4.5 so I hope that's not the case.
You have to download the "NET40" version and reference this.
I just installed the mono last version and the mono develop, here http://www.mono-project.com/Sybase they refer the dll Mono.Data.SybaseClient, but I can't find it anywhere, can you help me please?
The Sybase client library has been dropped in Mono 2.8 due to lack of users.
I've already dived into SQL clr programming. Unfortunately my first attempt is troubled.
My C# assembly code is just so:
enter code here
public partial class FirstCLRRoutines
{
public static int GetCLRFrameworkMajorVersion()
{
return System.Environment.Version.Major;
}
}
And SQL code is:
USE master
GO
CREATE ASSEMBLY [Chapter2.FirstCLRRoutine]
FROM 'D:\projeler\SQL_CLR\SQL_CLR\bin\Debug\SQL_CLR.dll'
But I get this error message from MSSMSE:
Msg 6218, Level 16, State 3, Line 1
CREATE ASSEMBLY for assembly 'SQL_CLR' failed because assembly 'SQL_CLR' failed verification. Check if the referenced assemblies are
up-to-date and trusted (for external_access or unsafe) to execute in
the database. CLR Verifier error messages if any will follow this
message
I just encountered exactly the same problem.
This is an old page, but first, formost and finally, the DLL must be built with .NET 2.0. SqlServer 2005 is built with .net 2.0, because that is the latest available when it was written. SqlServer 2008 might also have the same issue.
The DLL and the SqlServer must both reference the same .NET framekwork version. Once I figured this out, I created a separate project under 2.0 and shazam! worked perfect first time.
To see what version of .net your sql server uses:
select * from sys.dm_clr_properties
The accepted answer, while seeming to resolve the O.P.'s issue, is only partially correct and presents an overly simplistic explanation of the underlying cause, which could lead other people with a similar problem in the wrong direction.
The problem with the accepted answer is a misunderstanding of the .NET environment, and that same misunderstanding can also be seen in the Question itself. Within .NET, the CLR and the Framework are two separate things, each with their own versions.
The CLR (Common Language Runtime) is what executes managed code. This is not updated nearly as often as the Framework. The .NET Framework is a collection of libraries that provide the basic means of interacting with a particular version of the CLR.
A single version of the CLR typically has multiple versions of the Framework that it works with. A single version of the Framework, however, only works with one specific version of the CLR. For example, CLR version 2.0 works with Framework version 2.0, 3.0, and 3.5, while CLR version 4.0 works with all of the 4.x versions of the .NET Framework (i.e. 4.0, 4.5, 4.5.1, 4.5.2, 4.6, etc). To see the chart of CLR verion to Framework version relationships, see the MSDN page for .NET Framework Versions and Dependencies.
With regards to SQLCLR code, SQL Server only works with a single version of the CLR, and the specific version depends upon the version of SQL Server. SQL Server 2005, 2008, and 2008 R2 work only with CLR version 2. Since CLR version 2 only works with .NET Framework versions 2.0, 3.0, and 3.5, this means that SQL Server 2005, 2008, and 2008 R2 only work with .NET Framework versions 2.0, 3.0, and 3.5. Of course, SQL Server 2005 only included .NET Framework version 2.0 so there are a couple of newer libraries in .NET Framework version 3.0 and 3.5 that don't work in SQL Server 2005 without manually importing them (i.e. System.Core and System.Xml.Linq). Along those same lines, SQL Server 2012, 2014, and 2016 are statically linked to CLR version 4, which works with .NET Framework versions 4.0, 4.5, 4.5.1, 4.5.2, 4.6.
With regards to the information returned from both System.Environment.Version (in the Question) and sys.dm_clr_properties.version (in the accepted answer), they are reporting the CLR version, not the Framework version. So be careful not to confuse those two things reporting 2.0 or 4.0 as meaning you can only use Framework version 2.0 or 4.0.
And fortunately, due to backwards compatibility, code compiled against the CLR 2 Framework versions (2.0, 3.0, and 3.5) will run without needing to be recompiled in SQL Server 2012 and newer, even though they are on CLR version 4.
So, you generally cannot go wrong with using a Target Framework Version of 2.0, but you most certainly can use Framework versions beyond 2.0.
For a more in-depth look at developing SQLCLR code, check out the following article (and the series in general), which I wrote:
Stairway to SQLCLR Level 5: Development (Using .NET within SQL Server)
USE master
GO
CREATE ASSEMBLY [Chapter2.FirstCLRRoutine]
FROM 'D:\projeler\SQL_CLR\SQL_CLR\bin\Debug\SQL_CLR.dll'
WITH PERMISSION_SET = UNSAFE
Try that, and let me know if that works.
The library, System.Environment, is not supported for CLR:
http://msdn.microsoft.com/en-us/library/ms403279.aspx
You can still use it, as indicated in the "Unsupported Libraries" section of the article above, but keep in mind that the code has not been tested for security and reliability. This can cause unpredictable results in a production environment, so think about the risks and carefully test before deploying.
Also, I believe it either has to have a strong name or be deployed to a database marked as "Trustworthy" before it will execute.
Short answer :
set Sql Server version and .Net Framework version on project property.
First of all you have to check set your project property. in project property set the version of sql server that you want to create CLR for it. then choose .Net Framework version . for example if you want to create CLR for SQL Server 2008 you have to set .Net Framework to 3.5 and for 2005 choose .Net 2.0.
i hope this solution help you.