Hope some one can help me figure this out.
Problem: I have a sql CLR project in visual studio 2013. Every thing seems to work as I can install the project on SQLServer and call its stored procedures etc. However I do not know how to control the version number of this assembly when its installed. When I run following command
select * from sys.assemblies
It results in following
name principal_id assembly_id clr_name
MyTestSqlClrProject 1 65612 mytestsqlclrproject, ***version=0.0.0.0***, culture=neutral, publickeytoken=null, processorarchitecture=msil
What I want to know is what do I need to do to control the version number
version=0.0.0.0
So that I can manually increment it or auto increment it whenever a build is successful..
I have tried to change project>Properties>Project Settings> On presented screen clicked on Advance which shows another dialogue box on(Data Tier-Application) this there is a field Version, but apparently changing this value does not have any impact on the version attribute when I get this result from the database.
Thanks
The VersionNumber is an Assembly property. It is the [assembly: AssemblyVersion("x.x.x.x")] attribute that is typically stored in the \Properties\AssemblyInfo.cs file of the project.
You can either edit that file directly, or you can go to:
Project (menu) -> Project Properties (menu item) -> SQLCLR (tab) -> Assembly Information... (button) -> Assembly Version (fields)
If you do not have an \Properties\AssemblyInfo.cs file yet, then entering any info into the Assembly Information popup will create that file upon clicking the OK button.
Please note that there is a bug in SQL Server that prevents the version number from being displayed in the sys.assemblies system catalog view IF the Assembly is not signed:
"version" incorrectly showing as 0.0.0.0 in sys.assemblies and ASSEMBLYPROPERTY(name, 'CLRName') for unsigned SQLCLR Assemblies
Signed Assemblies will show the correct version number in sys.assemblies. When using Object Explorer in either SQL Server Management Studio (SSMS) or Visual Studio to look at the Assembly properties, the correct version number is displayed even if the Assembly has not been signed. Still, it usually best to sign Assemblies anyway, so just sign them and you won't have any issues here (especially because MS might never fix it; I did report that bug on 2016-01-28).
In terms of auto-incrementing the version number, you can use an * in the last position to do that. For example:
[assembly: AssemblyVersion("1.2.3.*")]
or:
[assembly: AssemblyVersion("1.2.*")]
Beyond signing the Assembly, you should be aware of complications in loading the Assembly into SQL Server starting in SQL Server 2017. SQL Server 2017 introduced a new security feature ("CLR strict security", an advanced option) that is enabled by default and requires that ALL Assemblies, even those marked as SAFE, be signed with either an Asymmetric Key (i.e. strong name) or Certificate and have a Login (based on whatever was used to sign the Assembly) that has the UNSAFE ASSEMBLY permission. For details on how to make this work, with or without Visual Studio / SSDT, please see the following two posts of mine:
SQLCLR vs. SQL Server 2017, Part 2: “CLR strict security” – Solution 1
SQLCLR vs. SQL Server 2017, Part 3: “CLR strict security” – Solution 2
Please avoid the new Trusted Assemblies "feature" as it has many more flaws than benefits, not to mention it being entirely unnecessary in the first place given that existing functionality already handled the situation "Trusted Assemblies" was meant to address. For full details on that and a demo of the proper way to handle existing, unsigned Assemblies, please see: SQLCLR vs. SQL Server 2017, Part 4: “Trusted Assemblies” – The Disappointment.
Related
I have created a certificate, signed my assembly (UNSAFE) and it works, All as described there
https://nielsberglund.com/2017/07/01/sqlclr-and-certificates/
Now I need to deploy the solution to many customers databases. I do not want to change the TRUSTWORTHY setting.
Is it possible to deploy it do not using file system? I.e. now I am using the binary to create the assembly.
But how I can create the signed assembly and deploy it to other db?
Yes, you can create everything straight from T-SQL scripts and never reference the file system. It is possible to create a Certificate from hex bytes (i.e. VARBINARY literal), and you can get the string form of the hex bytes from a binary file using a small command-line utility I wrote, BinaryFormatter (open source; on GitHub). BinaryFormatter also works for converting the compiled DLL into hex bytes for use with the CREATE ASSEMBLY statement.
Also, I should point out that if you are using certificates, then you do not need to also enable TRUSTWORTHY. This is one of the reasons to use certificates. Just make sure to load the certificate into [master], create the associated login from the certificate, and grant that login the UNSAFE ASSEMBLY permission, all before attempting to load the assembly into any database. But, once the certificate is loaded, then you can load the assembly into any database with no more configuration needed (especially not needing to enable TRUSTWORTHY anywhere).
Also, if you are looking to streamline/automate your build process while still using certificates, please see the following two posts of mine:
SQLCLR vs. SQL Server 2017, Part 2: “CLR strict security” – Solution 1
SQLCLR vs. SQL Server 2017, Part 3: “CLR strict security” – Solution 2
Additional details can be found in my answer to the following S.O. question:
CLR Strict Security on SQL Server 2017
P.S. This process would be a thousand times easier if the CREATE ASYMMETRIC KEY command were enhanced to allow for being created from a binary string. I have made this suggestion on Microsoft Connect – Allow Asymmetric Key to be created from binary hex bytes string just like CREATE CERTIFICATE – so please support it :-).
When I try and register a signed C# assembly in SQL Server via the Object Explorer in SSMS by right-clicking on the "Assemblies" node and selecting "New Assembly", then my signed DLL via "Browse", I receive the following error:
CREATE or ALTER ASSEMBLY for assembly 'My Assembly' with the SAFE or EXTERNAL_ACCESS option failed because the 'clr strict security' option of sp_configure is set to 1. Microsoft recommends that you sign the assembly with a certificate or asymmetric key that has a corresponding login with UNSAFE ASSEMBLY permission. Alternatively, you can trust the assembly using sp_add_trusted_assembly.
Even though I've tried signing the assembly both through a "Signing" project-properties-generated PFX file and through an sn.exe-generated SNK file (linked through hacking the project file's AssemblyOriginatorKeyFile node), both result in the DLL still being reported as not having a "Strong Name" by SQL Server in the "New Assembly" dialog:
I've tried this with both a Visual-Studio-2019-generated Class Library project in both .NET 4.8 and .NET 4.0 and a Visual-Studio-2010-generated SQL CLR Database Project all to the same end.
I understand the error message suggests a security hack to workaround the problem (which I have also tried to no avail anyway) but I'm trying to avoid these as the database server is public-facing. How do I fix this properly?
Assuming that the DLL truly is signed, then you are likely missing the second step of the preferred method noted in the first part of the error message, specifically:
that has a corresponding login with UNSAFE ASSEMBLY permission.
That part is critical to this working properly. Prior to loading the assembly into SQL Server, you need to do the following:
create an asymmetric key in the [master] database from the DLL
create a login from that asymmetric key
grant the new login the UNSAFE ASSEMBLY instance-level permission
Then you can load any assembly into any database so long as it has been signed by that same strong-name-key / pfx file (which can be several if you have multiple projects in your solution).
Even though I've tried signing the assembly both through ..., both result in the DLL still being reported as not having a "Strong Name" by SQL Server in the "New Assembly" dialog:
Correct. This is due to either poor UI design, or a bug. When creating a new assembly, the "Additional properties:" fields do not reflect the values of the file indicated in the "Path to assembly:" field. Most likely this is just the "assembly" dialog for all assembly-related stuff, and it works just fine for assemblies that are already loaded into SQL Server, but not for what you are attempting to load. If the intention was to peek into the file to indicate the current values of whatever is found at the path specified in the "Path to assembly:" field, then it's a bug (but I suspect it's the former). I have reported this to Microsoft here:
SSMS: "Additional properties" in "New Assembly" dialog is misleading as it doesn't describe DLL being imported
For info on working with SQLCLR in general, please visit SQLCLR Info
As a .NET Desktop developer, I have a lot of experience working with various databases that are already up and running; but I'm not a DBA. I'm currently working at a company where I am ther only software guy here to build them software from scratch -- their previous enterprise-level solution was an Access database with macros and a couple forms built it. So, I basically have no one else to go to.
With that preface, how the heck do I get a database -- ANY DATABASE!!! -- added to my VS solution? I've been beating my head against this for almost 6 hours and have made zero headway. At this point, I'm ready to say, "Screw MS databases!" and start looking at MySQL or PostgreSQL or something.
The desktop application I'm developing has to work whether there is an internet connection or not, so I need a local database that installs with ClickOnce. From what I've found so far:
SQL Server [Express] 2016+ requires Windows 8 or later (a non-starter since 95% our customers are still running Windows 7)
SQL Server Compact is being deprecated and won't work past VS2013
I think LocalDB is what replaces Compact in 2016+ (?)
Okay, so I started with this tutorial:https: //learn.microsoft.com/en-us/visualstudio/data-tools/create-a-sql-database-by-using-a-designer However, trying to add a "Service-based Database" just gives me this error once: "The 'DBProviderFactories' section can only appear once per config file." I try again and get this error repeatedly: "Unable to find DbProviderFactory for type System.Data.SqlClientConnection" I've Googled both errors and all the answers that I've been able to find pertain to VS2010 or earlier and their solutions are either not applicable or don't work.
Next, I tried this tutorial: https://msdn.microsoft.com/en-us/library/aa983322.aspx I've tried adding new data connections through the "Server Explorer" panel. I don't see "[*] Compact" as an option. When I try "Microsoft SQL Server Database File", I just get the error: Unable to find the requested .Net Framework Data Provider. It may not be installed."
I've even tried adding data sources through the "Data Sources" panel; that doesn't work either.
I've installed the "Data storage and development" addon from the Visual Studio Installer, several versions of SQL Server 2014, SQL Server Compact 4.0, and maybe a few other executables from Microsoft's website.
Nothing works.
Help...
I think I just found it!
Evidently, there are "machine.config" files on your computer. Search for them all, and make sure that there is only a single tag for "DbProviderFactories". I can add a database object now. Hopefully, this puts me in business...
https://social.msdn.microsoft.com/Forums/vstudio/en-US/7b4f353b-77fd-427c-976b-5968abc88c13/visual-studio-2010-unable-to-find-the-requested-net-framework-data-provider-for-sql?forum=vseditor
If what you are saying is that you are writing a browser based application - then one would migrate the tables to SQL Server (Express) or even MySQL - it really doesn't matter. Then write a new web app. The existing Access app would serve as a model for seeing features & screen layout but is otherwise not portable.
On the other hand, if you are re-writing a Windows application; then the decision is whether the payload requires a server solution or if one can stay at the PC level. If the payload is suitable for PC then a re-write using either Visual Studio or Access again.
Access is a front end db - the tables in the back end whether they be stored in SQL Server or an Access file are entirely passive. All the processing is done by the user's PC. If the payload allows that then this is the lowest cost re-write option.
If you've outgrown a PC level payload - then one must develop a back end database feature set with a more passive front end.
I have a solution in Visual Studio 2013, where among the others I have also a Database project. This project contains some .sql written in T-SQL.
IntelliSence and Parse (SQL (on visual studio menu) > Parse) do not work. I have gone through this Troubleshooting guide and many question on SO, but nothing worked.
As I understand is something in project setting that I need to configure or some leftovers I need to clean.
Any suggestions ?
In brief
IntelliSence is enable
SQL CMD is Disabled
In SQL Server Explorer there is an entry (localdb)\ProjectsV12 containing my DB.
Other solutions opened on the same instance of visual studio work fine
ReSharper is installed but is not the issue (I also tried without it)
Note:
The solution (the one that has issues) was created in a previous version of Visual Studio.
Update 15/12/2015
After some digging I found out that the issue may has something to do with the .v12.suo file (which is located alongside with .sln file and is hidden). Copping this file from a similar solution (one that IntelliSence works) eliminates the problem.
Another workaround that it may help, is to go to the "Database Project" properties (right click on the project in Solution Explorer and then select Properties), on the Debug tab and press Restore Default in "Target Connection String". In my case this just changes the Initial Catalog= value to Database and like "magic" IntelliSence works again! (in some cases it may need to restart the Visual Studio)
After this even if I restore (using Edit) the "Target Connection String" to the previous values the IntelliSence continues to work.
I'm trying to do a simple call to a database stored procedure from a C# application.
I'm following a guide like, e.g., this one or this one.
Both of these have the same basic steps.
Add a LINQ to SQL .dbml item to my project
Connect to a database in Server Explorer
Drag a stored procedure from the Server Explorer onto my .dbml designer window
But step 3 doesn't work. I have my stored procedure and my designer window, but I can't drag the sproc. I don't get a plus sign, or a "not allowed" sign. It's just a non-dragable object.
I can't find another way to add my sproc to the .dbml file. And I can't find anyone else who has had this problem. Every source simply says to drag it over.
What could I be doing wrong here?
Screenshot:
Turns out the solution was that I had the wrong version of a .dll for Visual Studio.
I noticed I was getting exceptions when performing actions in the Server Explorer. Googling the exceptions led to this question which points to this dll
C:\Program Files (x86)\Common Files\microsoft shared\Visual Database Tools\dsref80.dll
as the issue.
I replaced it with the corresponding copy from one of my teammates and it now works fine.
I had also installed VS 11 Beta and the designer was working fine until I uninstalled it. I had to delete the DLL manually at the above location and repair the installation by finding Visual Studio 2010 in Programs and Features and selecting Uninstall/Change and then Repair. The installer will replace the DLL file that was deleted with the correct version.
For anyone that can drag the sproc, but sees no result (the sproc simply does not show up in the functions pane): make sure that the sproc only returns datatypes that L2S understands. For example you can not return a geography field.
Editing .dbml files with a designer surface requires the LINQ to SQL tools which are not installed by default as part of any of the workloads of Visual Studio 2017. It can be installed by selecting the "LINQ to SQL tools" item under the "Code Tools" category in the "Individual Components" tab of the Visual Studio installer.