I cannot find a patch note anywhere as to why GetConnectionWithLock is removed from MvvmCross.
It is still listed in the docs but not it no longer exists in the IMvxSqliteConnectionFactory in version 4.4.
Should I just switch to GetConnection now or GetAsyncConnection and should I manually use the lock(object)?
We switched away from using the SQLite.Net-PCL library from Oystein Krogh to use Sqlite-net-pcl from Frank Kreuger, because the former does not seem to get any updates and abandoned by the author. The switch was mainly due to lacking Android N support.
However, we are removing the SQLite plugin in next release, since there is not much point in having a light wrapper which only registers the plugin.
Related
I've got a WPF App using the latest version of Prism for WPF (6.3.0) and Unity. Just a few modules. It works great.
When I manage NuGet packages for my solution, it tells me that there is a new version of Unity (5.4.0) available. Unfortunately, if I try to update to that version, I can no longer build.
It's pretty clear to see why: Upgrading unity via this method removes all references to it (Unity) from my project. Specifically the following 3 references completely disappear from all my projects without any replacement:
Microsoft.Practices.Unity
Microsoft.Practices.Unity.Configuration
Microsoft.Practices.Unity.RegistrationByConvention
(The Prism references remain, of course)
Error messages tell me that IUnityContainer is defined in an unreferenced assembly (Microsoft.Practices.Unity. 4.0.0.0). Given that it removed those assemblies, this all makes sense.
If I then try to go looking to add Unity back in, the Add Project Reference dialog cannot even find Microsoft.Practices.Unity when I search for it.
Now this isn't that big of a deal. I didn't need to upgrade. and it's easy for me to revert back. But I want to understand why this is failing for future reference.
Does this mean that Prism is tied to the older version of Unity and I just shouldn't upgrade?
Does this mean that types have moved to different namespaces and I need to make some other fix?
Some other reason?
Among the Unity 5 updates included a change of namespaces which as you noticed was a major breaking change. There are no plans for Prism 6 to support Unity 5, however the current Prism 7 previews (which is available for WPF) have updated both the Common Service Locator and Unity.
https://www.nuget.org/packages/Prism.Unity/7.0.0.336-pre
Hello We are using SBJson lib with version pod 'SBJson', '~>2.2.3' and want migrate to latest version pod 'SBJson5', '~> 5.0.0'.
What will be effort to migrate. I mean will it support old methods or do i need find the deprecated or changed methods or any other specific change.
Does any one used this lib or done migration with SBJson do post to this thread.
Please suggest some solution
I don't know how complicated your usage is, but you will definitively have to do some manual edits. I released version 3, with a major shift in focus towards streaming JSON way back in 2011, and I'm frankly amazed version 2.x.x even compiles today!
I tried to document the changes in the repo's NEWS file. When naming the releases I tried to follow SemVer, which means that every 2.x.x -> 3.x.x and 3.x.x -> 4.x.x and 4.x.x -> 5.x.x were named thus because they all broke backwards compatibility in some way.
For version 3 the API went through a big change to focus on streaming. Much of the API changed to support this. Version 4 further removed old methods that had been obsoleted in the 3.1.x, 3.2.x and 3.3.x series. For 4 -> 5 the breaking change was very small: the API stayed the same, and only the behaviour is slightly different. ("Naked Scalars", e.g. strings and numbers not wrapped it an array or object, is now accepted as per the updated JSON RFC.)
Have you considered whether you actually need to use SBJson? You may be better off just using NSJSONSerialisation. After all it's been in the iOS SDK since iOS 5, and in the Mac SDK since a bit after that. The main benefit of using SBJson is if you want to be able to start parsing JSON before it's fully downloaded. (Thus improving perceived latency.)
Other issues you may run into: I fixed a lot of bugs since 2.x.x releases, which means the parser is much stricter now than it was back then. (Due to bugs it used to allow all sorts of broken JSON, and broken UTF-8.) So if you rely on any of that behaviour you will be out of luck. Hopefully that's not the case :-)
I've been working to get NuGet versioning squared away in my ASP Core project and have come across some odd behaviors and would like to ask why they decided to do it this way.
1) Choose the lowest version in a range.
ex: [1.0.0, 2.0.0) Does not mean choose the most recentversion in 1.X.X but choose the lowest version, basically always 1.0.0 and never update.
2) Setting the specific version chooses a different version
ex: "1.0.0" will really select "1.0.X".
This one really concerns me. I want to make sure that when I tag code, using a specific version, all future builds will always use the same version. With this implementation, builds are not guaranteed to be reproducible!
I'm coming from using Maven and NPM and am trying to keep an open mind to other ways of doing versioning, but these two baffle me.
Please help me understand why they would do this, basically backwards from other package manager solutions.
You can use a floating version if you want the most recent version, ex 1.0.*.
I think you're incorrect here. If 1.0.0 is requested, it'll install 1.0.0 if 1.0.0 is available on the NuGet server. If it's not found on the server, it'll install the next closest version found, 1.0.1.
This is pretty well documented at
http://docs.nuget.org/consume/ProjectJson-Dependency#dependency-resolution-in-nuget-v3-/-project.json
Can I just replace the two old version realm frameworks to the new version ones? Or what should I do?
Yep! If you're not using a dependency manager like CocoaPods or Carthage, you just need to delete the old framework folders and copy the new ones into the same place. Xcode should be fine handling that the next time you attempt to build your project.
If you are using a dependency manager, then you just need to hit the update command in their command line tools, and it'll be taken care of automatically.
Please keep in mind that Realm 0.97 has completely removed all of its previously deprecated APIs, so if you were using any of those, you will get build errors, but they'll be very easy to fix.
I cam up with the same question and while looking around came up with a good solution. This is in addition to what TiM has pointed out. Also, a few things to keep in mind:
I upgraded from version 1.0 to 1.0.1: so there weren't many changes to the framework and commands I used in my app.
I didn't use any special or very specific commands. Mainly the queries and writes/updates of objects. Nothing very fancy. If you have very specific requirements of Realm than I suggest look into those and see if there are any special changes to how they are managed.
Now to the steps:
Remove the frameworks from the "Embedded Binaries" section by clicking the "-":
General Tab - Embedded Binaries
Remove the frameworks from the project itself by right-clicking on them and select "Delete"
Navigator - Framework Files
Now just go and do the steps for installing the frameworks as found in the documentation "realm.io/docs/swift/latest/#installation-swift-22".
I understand this question is rather old, but looking through the SO I dint find a definite answer to this.
Hope this helped!
I just discovered work on Spring Security Kerberos/SPNEGO Extension on github: https://github.com/spring-projects/spring-security-kerberos
Since we still use 1.0.0.M2, I wonder if an update is recommended or where I can see how development on the new release is planned and making progress.
Thanks
I just wanted to update as well. The maven dependency link is broken at the moment (the one stated on http://projects.spring.io/spring-security-kerberos/). However the content is identical with 1.0.0.M2 anyway except for the packaging.
For that reason updating does not seem to be necessary.