Naclsdk list indicates pepper_49 as the stable release
C:\nacl_sdk>naclsdk.bat list
Bundles:
I: installed
*: update available
I sdk_tools (stable)
vs_addin (dev)
pepper_44 (post_stable)
I pepper_45 (post_stable)
pepper_46 (post_stable)
pepper_47 (post_stable)
I pepper_49 (stable)
pepper_50 (beta)
pepper_canary (canary)
All installed bundles are up-to-date.
But: in API reference page
Pepper C API Reference (Stable) saying: lists the C API for Pepper 48.
Pepper C API Reference (Beta) saying: lists the C API for Pepper 49.
This makes me think pepper_48 instead of pepper_49 being the stable release.
Also note, pepper_48 is NOT listed in naclsdk list.
Can anyone help clarify this for me please?
Got a valid answer from Native-Client-Discuss Google Group as the following:
https://groups.google.com/forum/#!topic/native-client-discuss/6ormRPg8yE0
Sadly the NaCl SDK is behind on publishing new releases. We are
working working on fixing that now:
https://bugs.chromium.org/p/chromium/issues/detail?id=648344.
For now, please consider pepper_49 the latest stable release.
I am not sure why this question has been down-rated...
Related
though the docs here (https://learn.microsoft.com/en-us/graph/api/chat-hideforuser?view=graph-rest-1.0&tabs=http) said we could use them, with c# sample code too, but we don't see them at all after having added the sdk to the project. Note we are already able to add new chat with members and fetch messages.
a few others too that have same issue:
https://learn.microsoft.com/en-us/graph/api/chat-unhideforuser?view=graph-rest-1.0&tabs=http
https://learn.microsoft.com/en-us/graph/api/chat-markchatreadforuser?view=graph-rest-1.0&tabs=http
https://learn.microsoft.com/en-us/graph/api/chat-markchatunreadforuser?view=graph-rest-1.0&tabs=http
is there any dependency or steps we missed?
resolved the problem -- somehow the version (4.34.0) I used was out of date, and the latest version 4.49.0 does have these APIs
MessagingRemoteException: An error occurred on client Build1660001055 while executing a reply for topic xvs/Build/16.6.0.1055/execute-task/CBREApp.iOS/e6f82e0002fCopy
TypeInitializationException: The type initializer for 'Microsoft.Build.Tasks.Copy' threw an exception.
PlatformNotSupportedException: Operation is not supported on this platform.
If you were like me who did not want to install the 16.7 Preview release just to get past this bug, the fix for this issue has luckily been released today (June 1st 2020) as part of update 16.6.1: Release Notes
Bug Report Link: xamarinios-fails-to-build-with-messagingremoteexce
(Note that as per this link, a temporary work around for this bug was to delete or change the build action of the iTunesArtwork#1x.png and iTunesArtwork#2x.png in your iOS project)
I submitted an update to the app store today and received the warning Deprecated API Usage - Apple will stop accepting submissions of apps that use UIWebView APIs
I searched my app and found that I do not use a UiWebView.
Is the UiWebView used in Here SDK 3.12 or the MSDKUI 2.1.2?
Sources of NMAKit does not contain any reference to UIWebView. However, I found at least one internal third-party dependency, which contains such reference.
3.13.2 version is planned to be released next week. Will let you know, if quick fix has been found and included in 3.13.2 or in next HERE SDK releases.
UPDATE:
HERE SDK 3.13.3 includes fixes for UIWebView warning and is available now.
HEREMapsUI (MSDKUI) still depends on 3.12. Please wait for the next release. Integration is not public yet, once available it will be announced on the MSDKUI release page.
MSDKUI 2.1.2 does not have any reference to the UIWebView.
I found the UIWebView usage in NMAKIT
From terminal I changed directory to the latest Archive, e.g.
cd ~/Library/Developer/Xcode/Archives/<date>/myapp.xcarchive/Products/Applications/myapp.app
Then used nm:
nm GuideMeToHERE | grep UIWeb
for framework in Frameworks/*.framework; do
fname=$(basename $framework .framework)
echo $fname
nm $framework/$fname | grep UIWeb
done
The output I got was:
NMAKit
U _OBJC_CLASS_$_UIWebView
Using the cosmos db sdk in a 1.0 function. UpsertDocumentAsync throws error "PartitionKey extracted from document doesn't match the one specified in the header". In my REST Api using the same cosmos db sdk v2.1.3 everything works fine. Only difference in packages is Newtonsoft.Json is version 10.0.2 in function and version 11.0.2 in REST Api. I'm wondering if it has something to do with Netwonsoft and the sdk usage of it may differ between versions. Anyone else having this issue that can shed some light?
It was indeed Json.net. I was upgrading to Azure Function 2.0 and it uses 11.0.2 version. So upgrading my other components to the newest version fixed the issue. Thank you for your quick reply.
I have an old Asp.Net web application using Unity for dependency injection.
Today I updated the Unity using NuGet to the latest version. On trying to run the application, I am getting an exception:
Unity.Exceptions.ResolutionFailedException: 'Resolution of the dependency failed, type = 'SOME.Services.ISomeService', name = '(none)'.
Exception occurred while: while resolving.
Exception is: InvalidOperationException - The property converter on type DAL.Repositories.SomeRepository is not settable.
The exception happened on line
_someService = container.Resolve<ISomeService>();
I am very new to Unity. Could you please help?
The newer versions of Unity have breaking changes.
You may want to stick with the older versions of the DLL until you refactor the changes.
v4.0.1 Version 4.x is dead. Loss of original signing certificate made
it impossible to release anything compatible with v4.0.1 release. To
give original developers a credit only about 60 issues were found
during two years in production. To move on and enable further
development version v5 has been created.
v5.x Version 5.x is created as replacement for v4.0.1. Assemblies and
namespaces are renamed and refactored but otherwise it is compatible
with the original. v5.0.0 release fixes most of the issues found in
v4.0.1 and implements several optimizations but the accent was on
compatibility and if optimization would break API it was omitted. Once
stabilized, this version will enter LTS status and will be patched and
fixed for the next few years. There will be no significant development
in this line.
Check their road map here.