I have a MFP 7.1 server with one runtime currently deployed for use.
Will the application binaries already installed on phones still work after applying the fixpacks?
Or do i have to plan to upgrade the runtime and deploy a new application binary?
The fix pack you apply will typically be to the MobileFirst Studio or the Server runtime. If you've applied it to MobileFirst Studio & rebuilt your app, then this must be redistributed to the end users to gain advantage of any fixes that are part of this fix pack.
Related
I am planning to migrate an existing worklight 6.1 application to mobilefirst 7.1.Currently three versions of application are running.
I am following this as my reference :
http://www.ibm.com/support/knowledgecenter/SSHS8R_7.1.0/com.ibm.worklight.upgrade.doc/devenv/c_upgrade_to_srvr_in_production_env.html
But I am going to do some process change in this process because I have a fresh server for mobilefirst 7.1.
As in mobilefirst 7.1, there are many changes in workligth db in compare to worklight 6.1, I will create a configuration first on mf server using server configuration tool. Then I will create a runtime environment for my application with lates mobilefirst 7.1 war.
But while doing that if I give reference of older database(worklight 6.1) as database in server configuration tool for migration , are all version which are currently running on worklight will run without error on mobilefirst 7.1?
Should I keep contextroot of mf runtime same as worklight (previous) ?
All I want is older versions to be up and running after this deployment.
I will enable mf server on same Domain/IP which is configured with worklight 6.1 server.
But while doing that if I give reference of older database(worklight 6.1) as database, are all version which are currently running on worklight will run without error on mobilefirst 7.1?
Not sure what you mean here... You can't have a 7.1 server with a 6.1 database.
What you can have is an application server (liberty, was, tomcat, ...) that runs TWO MobileFirst war files: that of 6.1 and that of 7.1, so that existing 6.1-based apps will continue working as-is, and 7.1 new clients will connect to the new server...
When you have the two servers running, you can then start "migrating" users by blocking the 6.1 app in the MobileFirst Console to the 7.1 version of the app.
If you need further assistance with this, you should open a PMR. Stack Overflow is not the place for this type of question, plus you may need official support, which, again, that's what a PMR is for.
I just upgrade my current mobilefirst studio to latest version. After the Update i can't able to open the my projects.It's showing the following error when tried to open the project.
"Migrating the ProjectName project from version 7.0.0.00.20150610-1353
to version 7.1.0.00.20150807-0630 has failed because There is no
available migration path. Use the latest MobileFirst Studio or the
latest "IBM MobileFirst Studio Upgrader" from IBM Fix Central site
http://www.ibm.com/support/fixcentral/ "
This question is useless without providing a project that demonstrates the failure in upgrade in MobileFirst Studio.
As such, the only alternative I can offer is for you to create a new project in MobileFirst Studio, and copy over into it your web resources to the corresponding folders: the JavaScript, CSS and HTML, as well any custom classes you may have implemented.
I know that there is a separation of the lifecycle of the MFP Studio and MFP Server. What happens if the development team updated the Studio with a fix? In other words, is it supported to deploy a runtime for example v6.3.0.00.20150214-1702 to a MFP Server v6.3.0.00.20141127-1357?
The scenario you've described it a supported scenario. The MFP Server should be able to host a .war file generated from a newer MFP Studio build of the same major version (6.3, and I believe support from this scenario exists starting 6.1 or 6.2).
Of course, if you encounter a problem you should probably open a PMR on that. :)
I created a hybrid worklight application having iPhone as the target environment using Worklight Studio 6.0. The application has 1 html file which has HelloWorld written in it.
I then migrated my worklight project to Worklight Studio 6.1. The application builds successfully, but while running the application, the application hangs at the splash screen and does not show the HTML page.
Is there any step that I am missing in the migration activity for iOS?
This actually sounds very much likely a recently fixed APAR: PI21872 ON IOS, INSTALLING THE SAME APPLICATION TWICE (WITHOUT unistall) would perform FREEZE AT THE APPLICATION START-UP.
While the APAR title does not match your problem description, it does match the issue that was resolved internally.
Either take a look at IBM Fix Central and install the latest 6.1.0.1 available there, or
Open a PMR and request the latest available Worklight 6.1.0.1 iFix
Verify that your issue is then resolved.
Also, since you say you have only "hello world" in your application, you could just create a new project in 6.1 instead?
Background
We're using System Center 2012 to deploy a Windows 8 Metro-style application to Samsung slates in the field running Windows 8 Enterprise x64. The slates are joined to the domain and have a persistent DirectAccess connection back to it, allowing System Center to push applications and updates to the devices.
We have to deploy our application to potentially hundreds of devices in the field, which is why we went the System Center route. The code signing cert is installed on every device using Group Policy. To deploy the application, you simply provide the package output and specify the collection of devices to install it on. The app just shows up on the device in a few minutes.
The problem we're having is that when System Center deploys our application, the SQLite dependency is lost and none of our data access works.
About our project
Our application is a WinJS application that uses SQLite as a backend. However, all our data access code is in a C# WinMD project which the WinJS project references. We're using the sqlite-net library to talk to SQLite - we included the source for that in our C# project.
In Visual Studio, we installed the SQLite for Windows Runtime extension as described in Tim Heuer's article. The Metro application references this.
Testing using other deployment methods
SQLite data access from the application works fine when you debug or run it locally - in both Debug/Release and x86/x64.
The app packaging process provides a PowerShell script that you can use to install the application and a developer license if necessary. When installing our app using the PowerShell script, SQLite data access also works fine. Verified this by packaging and installing both Debug/Release and x86/x64 versions of the app.
Troubleshooting
When the application first tries to use SQLite, we see an exception about it not being able to find the sqlite3.dll.
We've tried/verified the following:
Confirm that we're deploying a Release/x64 build
Examine the appx in WinRAR and verify that it contains the sqlite3.dll
Reference the "SQLite for Windows Runtime" extension from the C# project instead of the WinJS project
Also reference the C++ runtime, this caused System Center to fail when deploying the app. Don't know why yet, but looking into it.
UPDATE
The issue is that System Center is having trouble deploying the Visual C++ Runtime Library dependency that the SQLite library needs. So unfortunately this isn't a programming question anymore. We're getting some help on this and I'll post the fix.
I wanted to post the details of a temporary fix that we're going with. We've also gotten closer to the root of the problem, so I wanted to provide those details as well.
Recap of Issue
When referencing the Visual C++ Runtime Package from our Metro project, System Center is unable to deploy the application to the devices because there is a problem deploying the proper version of the dependency for the appropriate architecture and build flavor.
Our development machines running Visual Studio 2012 (and packaging the project for deployment) are using a newer version of the Visual C++ Runtime (50727) than what is available in a fresh installation of Windows 8 (50712).
Worked with the System Center team and confirmed that this was a bug in the version we were using and has already been addressed in future builds. We're going to work on upgrading the environment but that will take a couple of weeks.
Workaround
I confirmed and tested the following workaround:
Remove the reference to the Microsoft Visual C++ Runtime Package from the Metro project
Install the x64 version of the Visual C++ Redistributable for Visual Studio 2012 - http://www.microsoft.com/en-us/download/details.aspx?id=3
Deploy the application
Works like a charm because the correct version of the dependency is there already. Obviously not a long term solution if we choose to also target x86 and ARM, but will get us over this hump.