Where can I find for download an old GAE SDK, say 1.9.15 ? I need to find out coverage and maybe use 3rd party API, which do not work well with the recent version.
It depends if the respective SDK is still officially supported or not. Both kinds are available in the appengine-sdks GCS bucket.
No longer supported SDKs (like the 1.9.15 one you're seeking) are available in the deprecated folder. Note that they may be under a subdirectory named as the version number without the dots, i.e. 1915 for 1.9.15).
Still supported SDK versions are available in the featured folder.
Related
GAE/J team decided to retire App.cfg and asked everyone to move to Cloud SDK (based Maven or Gradle).
We have been using GAE/J for eight years, and we are using DataNucleus V1.
The reason that we still use DataNucleus V1 is that you can not upgrade to V2 or v3 without losing your information since they are not backward compatible (one to many relationships are not working after upgrade).
From some reason, we can not make DataNucleus V1 work with GAE/J Cloud SDK. Do you know if GAE/J stopped supporting this version? (and only support V2/V3?)
Update
The Ant task enhance-classes is working well if I am using GAE tools jar from version 1.9.6.3, when pointing to the current GAE tools jar (version 1.9.8.0) it fails enhacing classes.
Apparently GAE cloud sdk appengine-java version 1.9.8.0 did not include the following libraries:
google-cloud-sdk\platform\google_appengine\google\appengine\tools\java\lib\opt\tools->
datanucleus\v1(few jars files)
and
datanucleus\v2(few jars files)
The enhancer is looking for these jars in these directory structure which is missing.
Once you add these files and directories it is working well.
I also reported Google cloud team
https://issuetracker.google.com/issues/160624330
Update
After a few days that the issue I opened was confirmed as a "bug" and was assigned, someone decided that the bug is actually "Won't Fix (Intended Behavior)". If someone feels like me that this is a critical issue, please update your thoughts via the issue tracker link.
When submitting Excel add-in to the office store. Which version of the Excel API should be referenced in the manifest file?
We have experienced being rejected because we didn’t refer to the newest version of the Excel API.
But if our Excel add-in supports an older version of the API. Shouldn't we be referencing this?
There are several aspects to the versioning of the Office.js library.
First, there is versioning of the actual JavaScript source files. Fortunately, this part is pretty simple: you always want the latest and greatest of the production Office.js, which is conveniently obtainable through our CDN: https://appsforoffice.microsoft.com/lib/1/hosted/Office.js. The files are also shipped as a NuGet package to allow corporate firewalled development, but the NuGet may lag a few weeks behind the CDN -- and in any case, any Store-bound add-in is required to reference the CDN location. So, in terms of Office.js versions, there isn't really versioing there: there is simply the one and only evergreen, frequently-updated, always-back-compatible, Store-required CDN version.
(While on the subject of CDNs: we also have a beta CDN, available at https://appsforoffice.microsoft.com/lib/beta/hosted/Office.js. This one is great to testing newly implemented-but-not-yet-officially-stamped-as-done features, which you'll find in our Open Specs: http://dev.office.com/reference/add-ins/openspec. However, any new APIs therein should be considered as strictly "beta", and they may well be renamed, re-grouped, or postoponed -- so your app should not rely on them, as we explicitly reserve the right to break pack-compat on the beta branch. An API is not "done" until it is listed in IntelliSense ande Documentation as complete, until it's available on the Production CDN, *and until its isSetSupported returns true -- more on that momentarily).
The more interesting bit for versioning are the actual API capabilities that are offered by each host. The Office.js library will have the latest JS code to be able to run them, but older hosts might not be able to support some of the functionality. For example, if you look at https://dev.office.com/reference/add-ins/requirement-sets/excel-api-requirement-sets, you will see that the 2016 wave of Excel APIs -- grouped under the "ExcelApi" requirement set -- has had three versions to date: 1.1, 1.2, and 1.3. ExcelApi 1.1 was what shipped with Office 2016 RTM in September 2015; 1.2 shipped in early March 2016; and 1.3 shipped just recently, and is in the process of being rolled out to the CDN. Each API set version has a corresponding Office host version that supports this API set (for most APIs, there have to be both JS and host-side changes; it's fairly rare that something can be a purely-JS addition). The version numbers are listed in the table, and there are links below the table to find a mapping from build numbers to dates.
Each of the API set versions contain a number of fairly large features, as well as incremental improvements to existing features. The topic for each requirment set, such as the link above, will provide a detailed listing of each of those features. And as you're programming, if you are using the JavaScript or TypeScript IntelliSense, you should be able to see the API versions for each of your APIs displayed as part of the IntelliSense:
You can use the requirement set in one of two ways. You can declare in the manifest that "I need API set ExcelApi 1.2, or else my add-in doesn't work at all" -- and that's fine, but then of course you aren't able to service older hosts, and so your add-in won't even show up there. Alternatively, if you add-in could sorta work in a 1.1 environment, but you want to light-up additional functionality on newer hosts that support it, you can use the manifest to declare only your minimal API sets that you need (e.g., ExcelApi 1.1), and then do runtime checks for higher version numbers via the isSetSupported API. Neat ways to get environment (i.e. Office version) has a very detailed explanation of this isSetSupported API-checking.
Hope this helps!
The Go SDK currently ships with Go version is 1.6.2 but the most recent is 1.7.1 . I need some enhancements/bugfixes that were released since 1.6.2 . However, when I replace the goroot directory in the SDK directory that contains Go 1.6.2 with a symlink that points to 1.7.1, I get an error that has to do with not being able to find bin/goapp, which looks to be AppEngine-specific and not provided in the standard Go build.
Does anyone know a way to upgrade the Go available in the AppEngine SDK? Does this mean that the Go in production is also 1.6.2?
Unfortunately you're stuck with the Go version that comes bundled in the latest App Engine Go SDK.
Even if you "switch" it locally with Go 1.7.1 and somehow you manage to compile and run your app with Go 1.7.1 (by adding the missing files from the SDK's Go root), the production environment currently also uses Go 1.6.2, so your app and Go code will run into errors in the live environment when code that is missing from 1.6.2 is referenced. Most likely even the deployment would fail.
Also note that when you deploy your app to App Engine, only the source files are uploaded, and your app is compiled in the cloud. So you can't even "trick" it by compiling it locally and somehow "exclude" source files and upload only the binaries (binaries are not even uploaded).
You can't do anything else but wait for Go 1.7.1 (or a newer version) to make it to the SDK. Note that the Go version bundled in the SDK usually lags a few versions behind, because for it to become the "live" version, it usually needs modifications / altering for the sandboxed environment of App Engine (certain restrictions must be applied / implemented), and it needs further / additional testing / strengthening regarding security.
At this point you should be able to upgrade - App Engine has supported Go 1.8 since 2017 and recently announced early support for 1.9.
In general, though, you're pretty much stuck with the versions supported in production - there's no way to link in your own version of Go to the SDK, and I'd argue that it would be extremely ill-advised to do so even if you could.
I'm wondering if there is any way to run and test GAE Go apps using the standard go test || go build etc tools and if it's not possible what's the technical reason.
The Go App Engine SDK contains the standard Go packages and tools, but a modified version of them.
The GAE SDK also contains local versions of the GAE platform services API implementations which are not part of the SDK (not even the API). So you can't just use the standard Go SDK. When you build or test with the GAE SDK, the SDK takes care of a context mockup so your app will have everything (or most of the things) required to "feel" it is running in the GAE environment. The SDK also contains the sandbox restrictions that are in effect in the production environment (e.g. you can't write to local files).
Also note that some features of the GAE SDK also rely on a Python runtime (because the Go GAE SDK was created using the existing Python GAE SDK), not everything is rewritten in go.
So taking all these into consideration it would not be feasible to build/test using the standard Go SDK and it is not even possible.
I'm using Go for Google App Engine, which uses an older version of Go. I want to use a third party package that requires a newer version of Go (goauth). It is possible to use that package in my Google App Engine program?
Goauth uses strings.SplitN, which does not seem to be present in the GAE version of Go.
Not without hacking the source of oauth to make it compatible, I'm afraid.
Either that, or you can try and contact the author to see if they are willing to publish a version compatible with AppEngine's Go version.
A third option would be to find an older revision of oauth which is compatible with your Go version and just use that one.