I have created a sample application using service fabric with Docker support. the VS version is 2017 community, Docker community edition version 18.04.0-ce-win62 (17151) and Microsoft Azure service fabric SDK 3.1.269.
I am getting the below error at run time:
System.TypeInitializationException: 'The type initializer for 'System.Fabric.Common.AppTrace' threw an exception.'
Inner Exception : DllNotFoundException: Unable to load DLL 'FabricCommon.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
That looks like a mismatch between the SDK version that you're using and the version the cluster is actually running. SDK 3.1 was targeted against runtime 6.2, and it can't run on lower runtimes (think about it - protocols or features may be missing).
TLDR at this point you may have the SDK installed locally, but your cluster probably isn't upgraded to 6.2 yet so you can't deploy things built against that SDK to those clusters until the upgrade happens. This is the normal process.
Supported cluster versions and SDKs are here. Also you may be running into this since 6.2 was deployed and then pulled back (a new version is going to start rolling out soon). You can find more information about that here, here, and here. I expect there to be more updates when the final build starts rolling out again.
Related
Have multiple versions of Fabric runtimes on local machine (8.1, 8.2, and 9.0 series) which can be listed with:
Get-ServiceFabricRuntimeSupportedVersion
Have combed the Fabric documentation + web for anything about switching (changing) the SDK or Runtime version (effectively rolling back to an earlier installed version not the latest). Nothing. Anybody got an answer. Stopped investigating after trying:
Connect-ServiceFabricCluster
Unregister-ServiceFabricClusterPackage -Code -CodePackageVersion "9.0.1017.9590"
to back out version until I got to the one I want (8.2.1235.9590). But that fail with:
Fabric version has not been registered
Assuming this concerns only the current Powershell context. Start-ServiceFabricClusterRollback flops just like Unregister-ServiceFabricClusterPackage.
This might be very unhelpful, but I think the Supported Runtime Version is just which runtimes does the PS scripts support, not something about the local cluster.
The runtime you have installed is the latest one, so if you want to use an old one you have to uninstall the latest and find the bits for the old runtime and install that.
I am however, not entirely certain! It might be possible to switch runtimes, though it seems unlikely.
From the Control Panel choose Uninstall Programs and removed Fabric (6.0 SDK and Runtime). Restarted Windows (PC). Unclear if a restart is really necessary. Then opened the Web Platform Installer and through Spotlight searched for Fabric to click on Add. That put back 4.2.1235 of the SDK I needed. Done.
I have some problem with self-hosted Integration Runtime in Azure Data Factory V2.
I have a few VMs running 4.X.X IR software. Some of them had auto update enabled in DFv2
There was an update from 4.X.X to 5.X. After this, IR is unavailable from DFv2.
Looks like the IR services running on the VMs are pointing to a wrong execute path - using still 4.0. I can fix it manually with sc config or reinstall IR, but after reboot it doesn't work again.
Is that a bug? Can I somehow fix it without removing the VMs?
Update:
What I did - I went to Data Factory V2 Integration Runtimes and picked my self-hosted IR, went to Auto update and enabled it. My Virtual Machine hosting this IR was running an older IR software (4.X.X). There was an update to 5.X.X. Everything was working fine until I rebooted the VM. After this from Data Factory V2 Integration Runtimes I was seeing an error saying that my self-hosted IR is unavailable. I logged into the hosting VM and it turned out that IR software cannot start its service dmgsvc.exe. When you go to services.msc and check the Integration Runtime service pointing to the dmgsvc.exe, the path will be incorrect. What was wrong there? It was a catalog 4.0 instead of 5.0. IR software cannot start up correctly because of that and the error is Error 2: System cannot find the file specified. So what I did? I manually fixed it and it was working. But after the first reboot of the VM it was again pointing to the 4.0 catalog. I reinstalled the software and the effect was the same.
For the upgrade to version 5.x of the Azure Data Factory self-hosted integration runtime, we require .NET Framework Runtime 4.7.2 or later. On the download page, you'll find download links for the latest 4.x version and the latest two 5.x versions.
If automatic update is on and you've already upgraded your .NET
Framework Runtime to 4.7.2 or later, the self-hosted integration
runtime will be automatically upgraded to the latest 5.x version.
If automatic update is on and you haven't upgraded your .NET
Framework Runtime to 4.7.2 or later, the self-hosted integration
runtime won't be automatically upgraded to the latest 5.x version.
The self-hosted integration runtime will stay in the current 4.x
version. You can see a warning for a .NET Framework Runtime upgrade
in the portal and the self-hosted integration runtime client.
Refer: Troubleshoot self-hosted integration runtime
Recently we started getting a message on the Azure portal that our SF version on the cluster we use will become unsupported (5.7.198). Which I interpret as that we need to upgrade to 6.0.
Has anyone done such an upgrade on a prod system with real customers and data that should be kept safe?
Is there an upgrade we should follow (i.e. go through intermediate versions)
Any issues that I should expect?
Thanks!
I've created a simple Azure Mobile Services project and added the nuget package for MongoDB (package id is mongocsharpdriver).
The version I added is 1.10.0
When I deploy the project I get the following error:
"Found conflicts between different versions of the same dependent assembly 'MongoDB.Bson': 1.10.0.62. Please change your project to use version '1.9.2.235' which is the one currently supported by the hosting environment."
It seems like the Dlls from the package I've added are conflicting with an older version installed by default in the cloud environment.
Is there a way to get around this problem?
(While trying to figure out whats wrong I installed the nuget package WindowsAzure.MobileServices.Backend.Mongo which can't be installed because it requires mongocsharpdriver(=1.9.2) and dose not allow me to use my newer dlls.)
It seems I'll have to wait for microsoft to update the dll in Azure:
I have created a simple application using the Google App Engine
Environment
Eclipse 4.2 (Juno) Plugin - http://dl.google.com/eclipse/plugin/4.2
JDK 7
I was able to create a sample application and run it locally.
When I try to deploy it gives me an error
Error in eclipse
Deploying 'applicationname' to Google has encountered a problem.
Unable to update app: The application contains Java 7 classes, but the --use_java7 flag has not been set.
See the deployment console for more details
Unable to update app: The application contains Java 7 classes, but the --use_java7 flag has not been set.
The logs show
Unable to update:
java.lang.RuntimeException: The application contains Java 7 classes, but the --use_java7 flag has not been set.
at com.google.appengine.tools.admin.Application.createStagingDirectory(Application.java:576)
at com.google.appengine.tools.admin.AppAdminImpl.doUpdate(AppAdminImpl.java:370)
at com.google.appengine.tools.admin.AppAdminImpl.update(AppAdminImpl.java:53)
at com.google.appengine.eclipse.core.proxy.AppEngineBridgeImpl.deploy(AppEngineBridgeImpl.java:433)
at com.google.appengine.eclipse.core.deploy.DeployProjectJob.runInWorkspace(DeployProjectJob.java:148)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
I see someone has encountered the same error before
Failed to deploy to Google App Engine because --use_java7 flag has not been set
I installed JDK 6 but I could not get the application to work either.
What are my alternatives to getting the application to work? - some thoughts...
Use prior version of plug in?
Install JDK 6 by itself?
Some other options?
You have to use JDK 6.
Similar Question
Java Overview Docs
App Engine runs Java applications using the Java 6 virtual machine (JVM). The App Engine SDK supports Java 5 and later, and the Java 6 JVM can use classes compiled with any version of the Java compiler up to Java 6.