Iam trying to deploy a dotNet app in Azure App Service, but it doesn't work because the default version of msbuild is at 14:
D:\home\site\wwwroot>msbuild /version
Microsoft (R) Build Engine version 14.0.23107.0
Copyright (C) Microsoft Corporation. All rights reserved.
14.0.23107.0
I've tried to modify the deploy.cmd with the msbuild 15 path but it doesn't work. How can i simply update the default msbuild version to be at 15 ?
thanks
This has been discussed here: https://github.com/projectkudu/kudu/issues/2350
D:\home>set msbuild
MSBUILD_15_DIR=D:\Program Files (x86)\MSBuild-15.3.409.57025\MSBuild\15.0\Bin
MSBUILD_PATH=D:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe
To use it you will need to have a custom deployment script with at least these two modification:
pass the msbuild15.3 directory to nuget (nuget4 has dependency on it):
nuget.exe restore "{your .sln file path}" -MSBuildPath "%MSBUILD_15_DIR%"
use msbuild15.3 to build and publish:
"%MSBUILD_15_DIR%\MSBuild.exe {your build arguments}"
Having mentioned that, Azure manages OS patching on two levels, the physical servers and the guest virtual machines (VMs) that run the App Service resources. Both are updated monthly, which aligns to the monthly Patch Tuesday schedule. These updates are applied automatically, in a way that guarantees the high-availability SLA of Azure services.
While critical OS information is locked down from access (see Operating system functionality on Azure App Service), the Kudu console enables you to query your App Service instance regarding the OS version and runtime versions.
Kindly checkout the document OS and runtime patching in Azure App Service for more details on this topic.
I downloaded the trial version of Corda Enterprise 4.0 for evaluation . Wanted to try out the jmeter corda test suite.
The document says available to registered user of Corda Enterprise in the same location as the Corda Enterprise artifacts. is it available in the trial version ?
There is a problem with the current Corda Enterprise 4.0 Evaluation pack - it is missing the test suite zip file that contains the example files referenced in the documentation.
Update: The missing zip file has been added under tools/jmeter-testuite/jmeter-corda-4.0-testsuite.zip. Re-downloading the evaluation pack should resolve the issue.
After you unzip the Enterprise evaluation .zip file, the jmeter suite should be available under tools > developer-pack > repository > com > r3 > corda > jmeter-corda (you'll need to untar developer-pack.tar.gz).
The Corda Enterprise Performance Test suite is updated at Corda Enterprise 4.0 Evaluation pack.
We are considering over which JDK is best suited for the R3 Corda.
However there is some incosistency in the way framework suggests the deployment.
Oracle JDK –
Recommended as per the Corda documentation https://docs.corda.r3.com/getting-set-up.html
Open JDK –
The Corda framework has a defined gradle task for docker deployment as “DockerForm”. This task generates the artifacts which are useful for deploying the Corda node as a docker container. So this task generates a Dockerfile for each node. This file is configured to use OpenJDK by default.
Please let us know the rationale behind this. Does Corda 3.x version support Open JDK as well? Do we have any guideline on which JDK to use in what situation?
Another concern is that eventually Oracle JDK will be a licensed product in future. So does R3 have any plans to support Open JDK as well in future?
As of Corda 3.1, Corda only supports the Oracle JDK 8 JVM, with a minimum supported version 8u171.
There is no current plans to add Open JDK support, but that could change (if, for example, Oracle JDK became a licensed product).
We have a cordapp jar and a web application war that depend on corda version 'corda-3.0-RC01'. Our deployment includes a corda jar of the same version. We would like to upgrade to version '3.1-corda'. As I understand, it involves performing contract upgrades on the cordapp and updating the corda jar, cordapp jars and wars in the deployment. However, is it possible to stagger the update of the cordapp (through contract upgrades) by first updating the deployed corda jar and just the webapp war? Would this require the war to be built against corda-rpc version '3.1-corda'? Could you please advise on the best approach here?
Here is the docs for upgrading to Corda3.1:https://docs.corda.net/releases/release-V3.1/upgrading-cordapps.html?highlight=upgrading
However, keep in mind that Corda is currently on 4.0, and going to have another update during the summer.
We’re thinking about downgrading our Alfresco Enterprise 3.4.1 to Alfresco Community.
I’m used to Alfresco Enterprise, but I have no experience with Community version.
We’re using EMC, Alfresco Explorer and our own development based on Web Services API and Foundation API.
I’m worried about database migration. Could I simply configure Alfresco Community 3.4.e to use our Oracle Database for Alfresco Enterprise 3.4.1? Is the schema compatible for both Community and Enterprise distributions? Which version of Alfresco Community should I use? 3.4.e? What is the downgrade path between distributions? Is there any kind of correspondence between versions of both distributions?
Any downgrade experience, guide or any related information will be welcomed.
The Alfresco Community Edition is open source, and works with a fully open source stack. Your DB options are PostGreSQL (recommended) or MySQL.
Alfresco Enterprise supports the open source databases that Community supports, PostGreSQL and MySQL, as well as a few proprietary databases too. You can look at the Database Configuration page for more information. Support for Oracle databases is only available in Enterprise.
If you want to keep paying Oracle all that money for your database licenses, then you'll need to continue to pay a tiny fraction of that cost to Alfresco for an Enterprise License. Community, being open source, only supports a fully open source stack, so you can't use Community with your uber expensive proprietary database!
If you were using an open source database like PostGreSQL or MySQL, then you might be able to do the switch as part of an upgrade. Enterprise Service Packs (eg 3.4.1) are normally newer than the equivalent community release from that series (Community gets the bug fixes on Head). Moving from a 3.4.x enterprise service pack back to a 3.4 community wouldn't be recommended, but moving from 3.4.x enterprise to a 4.x community might work. However, that's not a tested migration path, so you could well be on your own... Alfresco QA tests community -> newer community, enterprise -> newer enterprise, and community upgrading to enterprise, which are the supported paths.
This question is similar with this one about difference between Community and Enterprise version
You can not use Oracle database for Community version. It is only available for Enterprise.
There is not downgrade path for any Alfresco versions. If you are using Enterprise 3.4.2 try to use the same Community version.
I searched the web for possibilities of a downgrade from enterprise to community version, too. What I found is the answer "You may be able to downgrade, however that is never supported or tested."
When downgrading, you have to keep in mind that the community version X usually has more functionalities than the enterprise version with the same version number.
So, downgrading is experimental. I have already seen log files where the downgrade failed.
Maybe it is an option for you to export all content and import this ACP file on the new system with the community version?
Please read your contract carefully. Support and Licensing might not be the same thing in your case. If you don't want to pay anymore to Alfresco, you might be entitled to keep using your current enterprise version, but you would not longer have support. Before considering downgrading, check your contract. If in the future you want to get support and upgrade again, it might just be easier to do it with your current Alfresco Enterprise version.
But, as I said, it depends on your agreement with Alfresco.
Migration of the Alfresco repo database is no fun at all. There is no official way switching databases and in 3.x version you may have serialized objects which could be stored by hibernate db specific. This changed a little when Alfresco removed most of hibernate dependencies after 3.4. It may be an option to migrate to 4.0 EE first, migrate the db to postgres (which is closer to oracle than mysql) and finally upgrade to Alfresco Community 4.2.f (latest version with Web Services API). This may be a lot of work (even in your code) but should work.
Here in Germany it is legaly problematic to limit software usage in time if you sell a support subscription (at least for the old contracts you may have) so customers here can request support for a time unlimited EE license key before canceling the subscription contract. I recommend you go this way and update your old 3.4 to the latest 3.4.x or 4.x enterprise version available and stay on Oracle db if you don't care these costs. This step should be done anyway ;-)
I have done it before in order to create a development environment in my local machine,
First, you cannot use Oracle database so you have to use postgresql (recommended) or MySql, exporting and importing the database is not recommended, so you have to create the repository hierarchy and fix the rules, etc., then copy all custom jars (jobs, actions, workflows...) and library from the lib folder to the new one,
If you are using an external application based on alfresco uuids, make sure you updated the uuids after creating the repositories and rules