My Xamarin app builds and runs fine for UWP, iOS and Android when I build from Visual Studio 15.9.15 or Visual Studio for Mac.
However, my main Windows 10 machine has Visual Studio 16.2.3. It consistently has a runtime problem with Android. On base.OnCreate(bundle) of MainActivity this happens:
Java.Lang.ClassNotFoundException: 'Didn't find class "md51558244f76c53b6aeda52c8a337f2c37.PowerSaveModeBroadcastReceiver" on path: DexPathList[[zip file "/data/app/MyApp.Droid-yK4jL0oczZScGLufK33mnA==/base.apk"],nativeLibraryDirectories=[/data/app/MyApp.Droid-yK4jL0oczZScGLufK33mnA==/lib/arm64, /data/app/MyApp.Droid-yK4jL0oczZScGLufK33mnA==/base.apk!/lib/arm64-v8a, /system/lib64, /system/vendor/lib64]]'
When I build the Android from my MacBook, the app runs fine. I also have a different Windows 10 machine with Visual Studio 15.9.15 that builds and runs fine.
protected override void OnCreate(Bundle bundle)
{
TabLayoutResource = Resource.Layout.Tabbar;
ServicePointManager.ServerCertificateValidationCallback += (sender, cert, chain, sslPolicyErrors) => true;
ToolbarResource = Resource.Layout.Toolbar;
base.OnCreate(bundle); <-- ERROR HERE
Xamarin.Essentials.Platform.Init(this, bundle);
CrossCurrentActivity.Current.Init(this, bundle);
global::Xamarin.Forms.Forms.Init(this, bundle);
FFImageLoading.Forms.Platform.CachedImageRenderer.Init(enableFastRenderer: true);
LoadApplication(new App());
}
The odd thing is that I can find the so-called missing file in the MyApp.Android\obj\debug\81\Android\bin\classes folder.
What's the deal with Visual Studio 2019?
Xamarin.Forms 3.6.0.344457
Updating/Repairing Visual Studio did not solve the problem.
Luckily I was in a position where I could flatten my laptop and reinstall Windows 10 and Visual Studio 2019.
This allowed me to finally deploy to Android.
Related
I'm working on a MSI installer for our java app using Jpackage.
Versions:
openjdk version "17.0.1" 2021-10-19
OpenJDK Runtime Environment Temurin-17.0.1+12 (build 17.0.1+12)
OpenJDK 64-Bit Server VM Temurin-17.0.1+12 (build 17.0.1+12, mixed mode, sharing
jpackage 17.0.1
OS Name: Microsoft Windows Server 2019 Datacenter
OS Version: 10.0.17763 N/A Build 17763
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Server
OS Build Type: Multiprocessor Free
Jpackage Usage:
jpackage --input ./home ^
--name "Acme Application" ^
--main-jar app.jar ^
--main-class org.springframework.boot.loader.JarLauncher ^
--java-options "-splash:$APPDIR/splash.png" ^
--java-options -Xmx2g ^
--icon resources/package.ico ^
--win-shortcut ^
--win-menu ^
--type msi ^
--app-version %1
Upgrade Process
The installation works fine and everything runs well. The upgrade process also works fine under normal circumstances. When the user tries to run the new MSI package while the application is still running, the MSI installer prompts the user to close the application before continuing:
Selecting to close the application and continue causes the application to close on the users desktop but the installer then prompts the user again with the same dialog. Selecting the same option (close and continue), allows the installer to complete but the user is then warned that they need to restart.
Upon restarting, it appears that application version 1.0.0 is still running. Checking the jar file signature before and after shows that installer failed to overwrite the original.
Event Viewer
Checking the event viewer, I'm only seeing a few things of interest:
Windows Installer requires a system restart. Product Name: *******. Product Version: 1.0.1. Product Language: 1033. Manufacturer: Unknown. Type of System Restart: 1. Reason for Restart: 0.
and
The Windows Installer initiated a system restart to complete or continue the configuration of '*******'.
Failing to Stop the Application
I also noticed that the application is not completely stopping. Looking at the task manager, it shows the application running under the user and then moves to background processes. This leads me to believe that it's still locking the jar file. The application stops normally under other circumstances so I'm not sure what's different here.
I'm assuming that I need to solve this mystery but I have no idea why the application wouldn't respond to the installer's close signal while working with everything else.
Alright, I've done some digging and this is related to JavaFX's lifecycle. Simply overriding the Application.stop method is not enough to properly shutdown on these types of close requests.
Two changes to my application fixed the issue:
Register a EventHandler on the primary stage onCloseRequest
Here I initialize my spring application as well as register the event handler to stop the application:
#Override
public void start(Stage stage) {
applicationContext.publishEvent(new StageReadyEvent(stage));
stage.setOnCloseRequest(event -> stop());
}
Ensure you have a call to System.exit in your EventHandler
Platform.exit is not enough to close the application under these circumstances:
#Override
public void stop() {
log.info("Shutting down application...");
applicationContext.close();
Platform.exit();
log.info("Shutdown complete");
// System.exit is required or the app will move to a background process on uninstall/upgrade
// events from Windows MSI installer
System.exit(0);
}
I couldn't find anything that explains this -- for some reason my .NET Core 2.0 ASP.NET application does not run as a DLL via:
dotnet MyProject.Web.dll
And instead I get the exception:
Unhandled Exception: System.MissingMethodException: Entry point not found in assembly 'MyProject.Web, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
namespace MyProject.Web
{
public class Program
{
public static void Main(string[] args)
{
LoadDependencies();
var host = new WebHostBuilder()
.UseKestrel()
.UseContentRoot(Directory.GetCurrentDirectory())
.UseIISIntegration()
.UseStartup<Startup>()
.Build();
host.Run();
}
private static void LoadDependencies()
{
DependencyLocator.Instance.DefineIfUndefined<IDataProvider, DataProvider>();
}
}
}
It runs fine as a standalone executable (when targeting a "Console Application" in the project's config), but now that I'm trying to deploy to a server that needs it to run via the dotnet command (as a DLL, i.e. "dotnet .\MyProject.Web.dll"), it seems to be having issues. I get the above exception on both my server and my local development box.
I'm kind of blown away that it cannot locate the Main method -- it's declared as static and in Program.cs. Am I missing something?
(EDIT: To clarify, the DLL I'm trying to run against the "dotnet" command is from the target compiling as a "Console Library," since my server is explicitly asking for a DLL, since they will not run executables).
OK, so this is annoying and will hopefully help someone else out.
My host wants to specifically run DLL's thru .NET Core ONLY. They do not allow for executables to be run.
Because DLL's are frequently built as "Class Library" output types on the project, I assumed that this was the workflow necessary to build it. However, I found out that whenever you build your project as a "Console Application," it builds a DLL in addition to an EXE. So, in the above example, MyProject.Web.exe and MyProject.Web.dll are both built when the output type is "Console Application."
MyProject.Web.dll that comes from "Console Application" is different than MyProject.Web.Dll that comes from "Class Library." The one that comes from "Class Library" will NOT have an entry point that can be discovered on it, which will lead to the problem above.
So, if you're getting this error, look for the DLL that ships with your EXE of the same name -- that's the actual DLL you'll want to run in your dotnet console (i.e. dotnet MyProject.Web.dll)
I'm trying to use the Xam.Pugin.Iconize.FontAwesome nuget package with my xamarin.forms (shared project) app - targeting Android only. The app compiles fine, but when running the app, I get the following exception:
System.TypeInitializationException: The type initializer for 'Plugin.Iconize.Fonts.FontAwesomeCollection' threw an exception.
The exception is thrown at the following line (MainActivity.cs OnCreate method):
Plugin.Iconize.Iconize.With(new Plugin.Iconize.Fonts.FontAwesomeModule());
No other details about the exception are shown.
I have the following nugets installed (all are the latest versions):
Xam.FormsPlugin.Iconize 1.5.0.13-beta
Xam.Plugin.Iconize 2.0.0.37-beta
Xam.Pugin.Iconize.FontAwesome 2.0.0.37-beta
My version of xamarin.forms is 2.5.1527436, which is within the required version range required by Iconize (>= 2.3.5 && < 3.0.0).
As per the instructions on the Xam.FormsPlugin.Iconize web page, in my OnCreate(Bundle bundle) method in MainActivity.cs I have set as follows:
base.OnCreate (bundle);
global::Xamarin.Forms.Forms.Init (this, bundle);
Plugin.Iconize.Iconize.With(new Plugin.Iconize.Fonts.FontAwesomeModule());
FormsPlugin.Iconize.Droid.IconControls.Init(Resource.Id.toolbar, Resource.Id.tabs);
The only version of Xam.Pugin.Iconize.FontAwesome I can get working is the 1.5.0.13-beta release, but this has lots of icons missing from the current FontAwesome collection, so would like to get the latest package working.
Hi Please can anyone help, I'm trying to get Service Fabric to Host a .Net Core Web API Restful service as a Guest Executable.
I'm guessing possibly incorrectly that I should be able to run the exe once I have done the full publish, but it fails when I do.
I have done the following...
Ensured the main Web API assembly and all referenced .NET Core assemblies are set to x64 Targets
Set the Output type to be an exe and have a program.cs as below...
public static void Main(string[] args)
{
var host = new WebHostBuilder()
.UseKestrel()
.UseContentRoot(Directory.GetCurrentDirectory())
.UseIISIntegration()
.UseStartup<Startup>()
.UseApplicationInsights()
.Build();
host.Run();
}
Done the command line stuff...
dotnet restore
dotnet publish -c release -r win10-x64
Made a Referenced to "Microsoft.AspNetCore.Server.Kestrel": "1.0.0"
in Project.deps.json in the resultant win10-x64 publish folder.
However when I execute the thing directly the console window reports a problem with the StartUp Constructor, i.e. when performing builder.build.
public Startup(IHostingEnvironment env)
{
var builder = new ConfigurationBuilder()
.SetBasePath(env.ContentRootPath)
.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
//.AddServiceFabricConfig("Config") // Add Service Fabric configuration settings.
.AddEnvironmentVariables();
Configuration = builder.Build();
}
I feel close to getting this stuff working and have added a Service Fabric Guest Host project to host the exe, but needless to say the node fails with the error shown below...
Error event: SourceId='System.Hosting', Property='CodePackageActivation:Code:EntryPoint'.
There was an error during CodePackage activation.The service host terminated with exit code:2147516556
What am I doing wrong?
After building and successfully running a self-hosted NancyFx application on windows with visual studio I went on and tried to run the application on linux with mono. I was able to build the solution (using xbuild) but when running the app I get a strange error:
Unhandled Exception:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. --->
System.TypeLoadException: Could not load type 'System.Net.HttpListener'
from assembly 'System, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'.
at Microsoft.Owin.Host.HttpListener.OwinServerFactory.Initialize (IDictionary`2 properties) <0x413ae4f0 + 0x000eb> in <filename unknown>:0
For some reason, the app tries to initialize class HttpListener from the System assembly, but HttpListener lives in System.Netassembly. I looked in the GAC folder and found that System.Net is there as expected. I moved a copy to the bin folder where the other dependencies of the app live but that didn't solve the problem. Any help would be appreciated!!
here is my OWIN-related code:
// Startup.cs
using Owin;
namespace MyApp
{
public class Startup
{
public void Configuration(IAppBuilder app)
{
app.UseNancy();
}
}
}
// Program.cs
using System;
using Microsoft.Owin.Hosting;
namespace MyApp
{
public class Program
{
static void Main(string[] args)
{
var url = "http://127.0.0.1:8080/";
using (WebApp.Start<Startup>(url))
{
Console.WriteLine("Running on {0}", url);
Console.WriteLine("Press enter to exit");
Console.ReadLine();
}
}
}
}
Yep, wrong assembly indeed.
Im not sure why yet, but I'm having the same issue with CENTOS only using mono 4.3.178. Debian Jesse using version 4.2.x had no issues. Several other Debian Jesse boxes I use to test seem to have no issues with 4.3.x. In my case I'm listening on an alternate port.
RedHat Strikes Again :/
A MUCH deeper stack trace into the IL seems to indicate that gcc on the machine you built mono on, and also the build essentials package have some extremely dated libs and even the compiler. I was surprised to see the number of warnings, nearly 70,000 as opposed to a typical 400 depending on the diversity of libs you have. I have about 10 hours to figure this out, so hopefully its not too bad.