Two part question:
How does one get the currently installed version of Realm in code? Swift 3, macOS. I was unable to location any Realm.version property - perhaps I overlooked it.
In a related question
What is the solution to upgrade Realm to the latest version within a project? After updating CocoaPods to the latest, and refreshing, pod install doesn't appear to update Realm. I have 2.0.3 installed and 2.2.0 is available.
If you're embedding Realm Swift as a dynamic framework directly, the version number is contained in the framework's info.plist file. It should be possible to access the plist during runtime; there's a few answers on SO discussing this.
Since CocoaPods creates dynamic frameworks for Swift, the above approach of accessing the info plists should work, but if it doesn't there might be other ways to access versions of pods.
In any case, I would definitely recommend you review why you're wanting to check the version numbers of your libraries. It's better practice to check a framework's capabilities at runtime (eg, testing a class you need exists etc) than to directly use the version number.
For your second question, you need to run pod update RealmSwift to get CocoaPods to check for an updated version of Realm.
Related
I recently upgraded Firebase in my Swift app because I wanted to add App Check and I decided to update all the pods. Was only 8 minor releases 8.8 => 8.16. Now I am receiving
Firebase Instance ID is not compatible with Firebase 8.x+. Please
remove the dependency from the app.
I have removed my pods, cleaned, rebuilt, reinstalled.
I have restarted, cleaned, built.
I have removed App Check.
I have removed Messaging (which I've never used except for an experiment once).
I have no reference to Firebase Instance Id except in the FIR files which are Firebase's. Tried to follow the get started in the Firebase docs and they say use the Swift Package Manager (not sure if that was instead of CocoaPods?).
Any insight into this? It's obviously a new version issue, but would love to have to newest version for security vulnerability and any performance updates they've done. But my last resort will be to downgrade back to 8.8.
I'm not a big fan of cocoa pods, and are trying to modernise a project, getting rid of all the cocoa pods for a start, and #flurry is one of them. is there a Swift Package manager implementation of #flurry
I don't think so no. Swift package manager is comparatively new so it would take time for developers to port their cocoapods to SPM. But, there is already a request to add SPM support that has been closed, due to the unavailability of support to add binary in SPM. Check this link.
I fell in love with Cocoapods and I want to migrate all my projects with it.
Before doing it, I've a few questions on how to handle external not-cocoapods frameworks in my projects.
1) Let's say that I'm using Cocoapods and I've included only AFNetworking framework.
At some point, I need to use some CoreGraphic animation and I need to use QuartzCore: AFNetworking is not using this framework, so QuartzCore is not included in my Pods project.
What's the best way to handle this situation?
Is better to think "I put all the frameworks in my Pods project, so in my "app project" I've only the code necessary to my app"? And if yes, how? Adding in my Pods.xconfig this code
OTHER_LDFLAGS = -ObjC ... -framework QuartzCore
? Or there are other (better) ways?
Or is better to think "this is not a Pod, so I add the framework on my "app project" as I've always done before"?
2) I've a library (saved in my HD) that is not on the main repository of Cocoapods and there is no Podspec file: what's the best way to include it on my project?
I create a podspec for that library and I link it using :local attribute on my Podfile
I add that library in my "app project" as I've always done
Of course every way works fine, so I'm not asking "How to add an external framework", I'm asking what's the best way to do it :)
Framework
CocoaPods tries, to the possible extent, to separate its files from your work. This is also needed because CocoaPods needs to control some files. For example the Pods.xcconfig is assumed to be under CocoaPods control and it is recreated during each installation. In other words any change that you make to it is lost.
So if you need a framework you should add it to your app project. In principle you should do it even if the framework is included by some Pods because they might be updated removing the dependency and your project would break.
Custom library
Both alternatives work, if you plan to reuse the library creating the podspec might come handy in future. You could also create a custom repo (see the wiki) so you don't need to use the :local option.
Is there anyway i can check if .NET 2.0 is installed without any errors?
The answer here led me seriously astray... i found microsoft's own documentation: .NET Framework 2.0 Redistributable Package Reference: Detecting Installed .NET Framework 2.0
This documentation states:
The Setup.exe bootstrapper should use the following registry key to detect the .NET Framework version 2.0.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727
It then verifies the existence of the entry value:
Install (DWORD value = 1)
Note The same registry key will be checked for all versions of Dotnetfx.exe regardless of language. Therefore, if you want to display dialogs in a specific language you should use the corresponding version of Dotnetfx.exe. You do not need to make any changes to the settings.ini file when deciding which version of Dotnetfx.exe to use.
works like a charm... i realize this question and answer is 2 years old or more... but i got here from a search engine, and this is here for the next person who does the same... hope this helps -ck
This blog post describes two options for checking for a .NET installation, as well as retrieving versioning information.
The second option (using CorBindToRuntime) will fail if the .NET installation cannot be loaded. This might help you determine if there are any errors in the install - or at least whether the framework loads properly.
If you're using ClickOnce as your publishing method, you can click on the "Prerequisites" button in the "Publish" tab of the project's properties and check the box for ".Net Framework 2.0". This will make sure that framework is installed before the program installs, and can fetch and install the framework if necessary, too.
In regular VS Setup Projects, right-click on the setup project, chose View->Launch Conditions and add it as a condition. Visual Studio should have added one for you that matches the target platform of the project.
Where can I find information about upgrading Magento Enterprise 1.7. to the latest 1.9. ?
There's no such documentation.
Your general approach:
1. Close production server
2. Backup all DBs and Magento installation
3. Turn off all your custom extensions and themes
4. Delete from HDD: core Magento modules, their layouts, all standard themes and cache.
5. Get 1.9 EE, copy it over your installation
6. Request Magento through http
7. Walk at your site, notice errors and warnings, fix them
8. Check documentation and update for your theme, whether it supports EE 1.9. Turn it on if it supports, otherwise you'll need another theme.
9. Check documentation and updates for all your custom extensions - whether they support 1.9. Turn them on - one by one.
You won't have any problem with upgrading all core DB data - it's made automatically.
You'll have problems with your custom theme, as you'll need new version with support for 1.9. And you'll need to check your custom extensions and upgrade their source and DB data to fit 1.9.
Generally all Magento upgrades work by running the updated code with the old database. The differences will be detected and incorporated automatically on the next page request. Magento keeps track of every module's version number for this reason.
Because there is a chance some modification will break it is best to do this on a new (temporary) site then add the modifications back in gradually. That way the old site is still active and uninterrupted.
I think there is no official documentation. The best way is to figure out what core functionality is used in your customizations and after that look at theirs realization in new version: does it changed or not.
To know what was changed in new version you could check changeslist