What are the benefits or impacts if we upgrade the manifest.json file's version in UI5?
In my manifest.json file currently "_version": "1.1.0" is maintained.
What will be the pros and cons if we change the version to "_version": "1.21.0"?
How will the overall application be affected?
The "_version" in manifest is the version of the schema the manifest file complies with. For using newer features in UI5, a newer manifest schema version might be required. On the other hand, each UI5 version does only work up to a certain manifest schema version as can be seen from the manifest.json documentation.
The version can be used for schema validation of the manifest file.
On the runtime side, there seems to be currently only one changed behavior based on the vesion of the manifest quite some time ago (since UI5 1.52, schema version 1.9.0).
Related
When offline I'd like to have the UI5 documentation saved locally.
It appears the docs contained in the runtime simply reference the official website and the only other form of downloadable documentation I could find is a PDF from SAP which is indeed well structured and cross-referenced.
Still, I wonder: is there a packaged version of the UI5 documentation ?
Using the Node modules for OpenUI5, I expected to find a separate package for the documentation: there is none. Serving the unzipped SDK with any local webserver works just fine.
I need to create a mechanism to request the latest version of my API. I know that you can specify a default version, but I don't need this. The purpose is to access to https://<server>:<port>/api/latest/<controller>, where latest is actually the most recent version. I need to define both versioning options: the major/minor and this one. Below are the two different ways to perform requests:
https://<server>:<port>/api/latest/<controller>
https://<server>:<port>/api/v1/<controller>
https://<server>:<port>/api/v1/<controller>
In the above example, the latest would point to the v2.
The difficulty here is that the built-in ApiVersioning from ASP.Net Core (the Microsoft.AspNetCore.Mvc package) doesn't support string named versions since the ApiVersion uses integers for versioning.
Is there any "clean way" to achieve it?
We have recently upgraded our API's (using Forms Authentication) Servicestack version 4.0.40 to latest stable version of Servicestack (V5.1.0). We use Autofac Ioc registration using InstancePerHttpRequest for API's (this is using Autofac.Integration.Mvc from Autofac.Mvc4 package).
Below code does not work anymore after servicestack upgrade.
this.UseAutofac(afcBuilder.Build());
Error CS0012 The type 'ServiceStackHost' is defined in an assembly
that is not referenced. You must add a reference to assembly
'ServiceStack, Version=4.0.48.0, Culture=neutral,
PublicKeyToken=null'.
So we have tried alternate ways to make it work using InstancePerDependency but that is causing missing "ASP.NET_SessionId" cookie value after API authentication.
Please suggest code to get actual "InstancePerHttpRequest" work with latest ServiceStack version.
I've already answered this question in ServiceStack Customer Forums but for anyone else's benefit with similar issues I'll include it below:
The issue isn't with ServiceStack or AutoFac it's with one of your dependencies which still has a binary reference to an old v4.0.48 of ServiceStack (highlighted in the Exception). You can't mix and match ServiceStack .dlls from different versions so you would need to re-compile whichever assembly has the old binary ServiceStack reference to use the version of ServiceStack you're using.
Autofac wouldn't have a dependency to ServiceStack, it would be one of your dependencies that is registered with Autofac. You can either use an Assembly inspector like JetBrains dotpeek and inspect the .dll references of each dll reference in your project or comment out registrations until you find the one with the dependency.
Basically you're unlikely to get anywhere focusing on ServiceStack or Autofac .dll's, you need to find the .dll that has a reference to ServiceStack v4.0.48 and re-compile it to use the version of ServiceStack you've upgraded to.
If you look at the dependency of Autofac.Mvc4, you'll see it only has a dependency to Autofac. Autofac's not going to have a dependency to ServiceStack v4.0.48, one of your own .dll's is going to have the old binary reference that's causing the issue.
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.
Can I expect that I replace the Java .jar files and client-side .js files of version 2.4 or 2.5 of CometD in an existing software that is running fine, with the same files in 2.9.1 and it all runs the same?
1- Are the API of CometD exactly the same on all 2.x versions?
2- Is there an upgrade guide that I can use?
Also, I noticed that on the client side, CometD 2.4/2.5 is not AMD and is a single file, but on 2.9.1 it is AMD-based. Is there a single .js file that contains all client-side CometD code?
You can expect upgrades from 2.4/2.5 to 2.9.x to be either without problems, or requiring very little changes, so yes, it should be typically be a drop-in replacement.
While you're upgrading, I suggest to move to CometD 3. You can find here the migration guide from CometD 2.x.
CometD 2.9.x is AMD compliant, and the single file you should include in your HTML is typically org/cometd.js along with a binding for a toolkit (either jquery or dojo).
If you use extensions, you should add also those, see for example http://docs.cometd.org/3/reference/#_primer, or if you don't want to use Maven, this other section.
Follow also the tutorials, that should get you going.
Full documentation link.