So Ive spent quite some time today with sql lite and saw the .net4 providers were very un stable. So I figured I'll use SqlCE. Its supposed to have a zero config/install instead its the most confusing way to deploy the thing.
I check numerous SO questions and these articles:
Link
Link
A More updated short guide:
http://robindotnet.wordpress.com/2010/02/28/how-to-deploy-the-sqlserver-compact-edition-software-locally/
So here is my problem, without the <runtime> tag bit, it WORKS on my DEV machine but NOT on XPSp3 without the SqlCE runtimes. It gives me a FileIOLoadException
WITH the <runtime> tag it works on XpSp3 but on my dev box it says :
Could not load file or assembly 'System.Data.SqlServerCe, Version=3.5.1.50, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I checked this answer but Im VERY confused. Also, apparently the msdn blog articles are off, you need to include 7 dlls all together. And the System.Data.SqlServerCe.dll and System.Data.SqlServerCe.Entity.dll both come from folder named "Private" where the runtimes are installed.
<system.data>
<DbProviderFactories>
<remove invariant="System.Data.SqlServerCe.3.5"></remove>
<add name="Microsoft SQL Server Compact Data Provider"
invariant="System.Data.SqlServerCe.3.5"
description=".NET Framework Data Provider for Microsoft SQL Server Compact"
type="System.Data.SqlServerCe.SqlCeProviderFactory, System.Data.SqlServerCe, Version=3.5.1.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91"/>
</DbProviderFactories>
</system.data>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Data.SqlServerCe" publicKeyToken="89845dcd8080cc91" culture="neutral"/>
<bindingRedirect oldVersion="3.5.1.0-3.5.1.50" newVersion="3.5.1.50"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
How in the world is this zero configuration!? I have no idea what really is going wrong nor what I did to make it right? Isn't there documentation on this anywhere Other than some old blogs?
Just simply put, once I need to deploy, I just want to be able to xcopy exe and other files and it should work.So where is the reference/msdn/documentation/step-by-step on how to deploy?
Also sqlce will work on a box with ONLY .net4 installed right?
I had a very similar problem posted on S.O. in 6851346, and I just solved it.
I don't know if you are still struggling with this, but I found a solution on Code Project called Creating a Private Installation for SQL Compact that fixed my problems right up.
I hope this helps others, too.
Do you use Entity Framework? If not, the runtime tag is not required.
You must change this: Version=3.5.1.0 (in the add tag) to 3.5.1.50, and make sure you use the System.data.SqlServerCe.dll from the Private folder (it has this special assembly version)
Related
I have an asp.net core web application that uses the MSOnline PowerShell module to interact with Office 365. When the Connect-MsolService cmdlet executes to authenticate with Office 365 I'm getting the following error.
Could not load type 'System.IdentityModel.Tokens.JwtSecurityToken' from assembly 'System.IdentityModel.Tokens.Jwt, Version=5.1.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
When running the same logic in another project via a unit test I do not get the error, the code executes as expected. Both the test project and the web project are using the same version (5.1.5) of the System.IdentityModel.Tokens.Jwt assembly so I don't understand why I'm getting this error when that logic executes in the web app.
I've read that a solution is to downgrade to v4 of the System.IdentityModel.Tokens.Jwt assembly but I know it works with 5.1.5 because my tests are passing. Besides, that's not an option for me because some of the aspnetcore assemblies require v5. Does anyone understand why this would happen in the asp.net core web app or know a solution that doesn't require downgrading the assembly?
Update:
It looks like my binding redirect is causing the problem. If I add the following to the app.config file in my test project it produces the error. This is very odd because 5.1.5 is the version of System.IdentityModel.Tokens.Jwt that's referenced, it's as if a different version is being used by default.
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.IdentityModel.Tokens.Jwt" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.4.0.0" newVersion="5.1.5.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
I ended up solving this by eliminating the binding redirect for System.IdentityModel.Tokens.Jwt. The binding redirect was automatically created because I was using the Auto-generate binding redirects option. I decided to just disable that option and manage the binding redirects manually to eliminate the unwanted redirect.
To make it simple I just copied the auto generated binding redirects from the output config file and pasted them into my projects app.config file. Then, I removed the System.IdentityModel.Tokens.Jwt redirect and with the Auto-generate binding redirects option disabled it only used the redirects in my app.config file instead of generating them which solved the problem.
I still don't understand why the redirect causes that error, hopefully someone will eventually shed some light on that but luckily I found a workaround.
One thing to note, if any of your dependencies use different versions of that assembly this obviously won't work. Luckily for me that isn't the case, at least for now.
I managed to get this to work by updating the assembly binding to exclude the version of System.IdentityModel.Tokens.Jwt that the Connect-MsolService was using. This worked. My updated assembly binding is:
<dependentAssembly>
<assemblyIdentity name="System.IdentityModel.Tokens.Jwt" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="5.0.0.0-5.6.0.0" newVersion="5.6.0.0" />
</dependentAssembly>
I am using the new nuget mechanism with PackageReferences in the csproj file.
When using the transient resolve no BindingRedirections will be created in the app.config.
For Example:
I installed System.Reactive 3.1.1 with the new nuget format in csproj.
Nuget creates no Binding redirects.
I tried Add-BindingRedirect in the PackageManagerConsole but nothing happens.
When I use the old format (packages.config) nuget creates the following Binding Redirect
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Reactive.Core" publicKeyToken="94bc3704cddfc263" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.3000.0" newVersion="3.0.3000.0" />
</dependentAssembly>
</assemblyBinding>
The next question is: Why only 1 redirect? System.Reactive depends on multiple nugets but there is only a redirect for one of them?
Can someone please explain this to me?
Thanks in advance
Lars
The idea is that the binding redirects are not added to the source App.config but are generated by during the build, so your resulting Foo.exe.config should have the necessary binding redirects depending on the dependency closure.
This is controlled by a property that is typically set automatically for projects using PackageReference:
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
Tried to update my EF package from nuGet, but I don't think it's installing correctly.
The installer seemed to go without a hitch, but after deleting my old .Edmx model, it will not let me add a 6.x model, as that option is greyed out with the error message "Your project references an older version of EF. To use the latest version exit this wizard and upgrade before performing this action."
Research indicated that I needed to delete the System.Data.Entity reference, but that didn't fix it. The problem seems to be that my EntityFramework.dll reference is still on 5.0 (runtime version v4.0.30319), even after the upgrade. I tried uninstalling & reinstalling EF and it still puts in the old driver under references. When I remove that EntityFramework reference, I'm able to add an EF 6 model, however since the driver is old, several namespaces aren't available that I need, such as System.Data.Entity.Core. Am I doing something wrong or do I need to download a new EntityFramework.dll driver separately, and if so, where would I get that?
I've been facing similar problem few days ago. Some referenced project were using EF v4.4.0.0, but EF I added to current project (through NuGet) was v6.0.0.0. The problem is, that namespaces (and some constructors) changed between versions.
You can hack it by adding
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="EntityFramework" publicKeyToken="b77a5c561934e089" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.4.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
</assemblyBinding>
But this causes that program sometimes fails...
Method not found: 'Void System.Data.Entity.DbContext..ctor(System.Data.Objects.ObjectContext, Boolean)'.
I think that the best solution is using same version of EF across the project. Unfortunately (as in my case), sometimes you have to downgrade to old version because some projects are widely shared across the team/company.
About SQL Server 2012 SMO
1. What types / methods / properties are added to v11.0.0.0 (2012) compared to v10.0.0.0 (2008)?
2. Should I use app.config to set assembly binding redirection to allow users without SQL Server 2008 while maintaining compatibility with 2008?
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.SqlServer.Smo"
publicKeyToken="89845dcd8080cc91"
culture="neutral" />
<bindingRedirect oldVersion="10.0.0.0"
newVersion="11.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
I answer the actual question below. But first, I see a potentially unrealized issue between your stated goal and your proposed solution. Namely, binding re-directs are not conditional. So if it cannot find version 11.0.0.0 it will crash rather than falling back on 10.0.0.0. So you would need to only modify the app.config when SMO 2012 is installed. If this is what you were intending, ignore the rest of this paragraph. A potentially simpler solution would be to simply install the version of SMO you decide to make your application dependent on. It is available as a separate install from SQL Server and you can have both 10.0.0.0 and 11.0.0.0 installed. Download Pages: 2012, 2008 R2, 2008. You will need SQLSysClrTypes.msi and SharedManagementObjects.msi
Now as to the actual question:
The only thing official I could find was Backward Compatibility in SMO. It looks good for what you are discussing, until you start looking at previous versions of the document. Namely, it appears relatively unchanged since the SQL2008 version.
According to that
SMO applications that were written using previous versions of SQL Server can be recompiled by using SMO in SQL Server 2012.
UPDATE: After posting I decided to try this with another project that previously had not been used in this way. It has issues because it also references SmoExtended. At least one type DeviceType in this case was moved between the Smo and the SmoExtended assemblies. However, the type remains in the same namespace. This is an example of a breaking change where only recompilation is necessary to use the new version. In short you are more likely to have success with redirecting assemblies if you do not use any of the Smo*Extended assemblies.
If all it takes is a re-compile. Then, yes, then assembly redirect a good chance of working (In that the application will run, that does not say anything about breaking change in behavior). The main time when I can think of where this would not be the case is when a type is moved between assemblies. Particularly if the same namespace is defined in both assemblies.
Since there does not seem to be a more detailed change list from Microsoft, you could use reflection to iterate over the members of the assemblies of you are really curious about the exact differences. You could also flip through versions of the documentation on msdn to see of you spot new classes/methods. But reflection would be better at telling you all the differences. Since MS did increment the version are some breaking change somewhere and/or the addition of new classes/methods. Thus you will need to test both ways to see if it actually works at runtime.
If you do try redirection note you will need to redirect all SMO assemblies that you reference, not just the main one. That means at least:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.SqlServer.Smo"
publicKeyToken="89845dcd8080cc91"
culture="neutral" />
<bindingRedirect oldVersion="10.0.0.0"
newVersion="11.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.SqlServer.Management.Sdk.Sfc"
publicKeyToken="89845dcd8080cc91"
culture="neutral" />
<bindingRedirect oldVersion="10.0.0.0"
newVersion="11.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.SqlServer.ConnectionInfo"
publicKeyToken="89845dcd8080cc91"
culture="neutral" />
<bindingRedirect oldVersion="10.0.0.0"
newVersion="11.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
I have such redirects in production and not had issue. Though YMMV. Currently we develop linking SMO 2012 on our machines, but create our build machine links SMO 2008, which means our build machine will throw a fit if we ever use something new to 2012 (has not happened yet). A bit risky because we could test locally and get different results than the release build would have (but thankfully we have a QA division what works with the release build, but also here we have never had issue.) In actuality it is more often I use the inverse of the above. I will compile an assembly on my machine and want to deploy it to clients that do not support SMO 2012.
In short there is a good chance you will have success, though you do so at your own risk.
I am getting the following error when referencing the assembly Microsoft.Office.Interop.Word in my asp.net application.
The type 'Microsoft.Office.Interop.Word.ApplicationClass' exists in both
C:\WINDOWS\assembly\GAC\Microsoft.Office.Interop.Word\11.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Word.dll
and
C:\WINDOWS\assembly\GAC\Microsoft.Office.Interop.Word\12.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Word.dll
Previously, I was getting the error but the 12.0.0.0 was in the PIA directory under Visual Studio, but the error message was the same, except pointing to a different path. Since then, I copied the dll to the GAC, but with the same error.
I thought that .Net was supposed to take care of this. Can anyone give me some help?
BTW, I am doing this using Visual Studio .Net 2008
This is from the previous answer, but with relevant information included, in case the reference dies of link-rot:
Problems with Primary Interop Assembly Versioning: Using the .config file and the assembly binding redirection, I've finally been able to get rid of the originally reported exception. I've created a .config file containing the information about the assembly binding redirections. The .config was then copied to a directory containing the hosting application binaries. Now both the old and the plugins coexist and work correctly without a need to use the Marshal.CreateWrapperOfType method when casting a COM component so it seems there is a workaround and I didn't even have to make changes to the GAC. There are still some issues to be addressed but for now it seems there is a plausable solution.
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="MyCompany.Assembly1.Interop"
publicKeyToken="25578904345626a0"
culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0"
newVersion="1.0.1.0"/>
<codeBase version="1.0.1.0"
href="F:\MyApp\bin\Primary Interop Assemblies\MyCompany.Assembl1.Interop.dll"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="MyCompany.Assembly2.Interop"
publicKeyToken="25578904345626a0"
culture="neutral" />
<bindingRedirect oldVersion="9.0.0.0"
newVersion="9.0.1.0"/>
<codeBase version="9.0.1.0"
href="F:\MyApp\bin\Primary Interop Assemblies\MyCompany.Assembly2.Interop.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
[there is more discussion of the underlying cause, other possible-but-awkward solutions at the link]