Hello i started off with a tutorial from Mono ZeroConf
When my code reahes the line
ServiceBrowser browser = new ServiceBrowser ();
i get a SystemException
System.Exception: No Zeroconf providers could be found or initialized. Necessary daemon may not be running.
So how do i run the necessary deamon or provider (on windows)?
You need to download and install Bonjour for Windows. On completing the setup the deamon should start automatically. Many of the available Mono.Zeroconf binaries are out of date and contain bugs. However, you can download and compile the latest version from github.
Related
Summary:
When I attempt to build and run my Uno WebAssembly on Ubuntu 20.04, it fails. The error cites a file or directory that doesn't exist.
Steps to reproduce:
Open Ubuntu 20.04 platform
Install .NET Core SDK 3.1.403
Follow the "Getting Started on VSCode" tutorial here
When you attempt to start the app with the .NET Core Launch configuration, note that the build fails.
Error Details:
/home/<user>/.nuget/packages/uno.wasm.bootstrap/1.3.4/build/Uno.Wasm.Bootstrap.targets(126,2): error : System.ComponentModel.Win32Exception (2): No such file or directory [/home/<user>/Projects/uapp/uapp.Wasm/uapp.Wasm.csproj]
What I've tried
My knowledge of Uno Platform is approximately 1 day old. I'm not sure I understand enough about it to even know what to try, but I have done these things:
Run dotnet run from within the uapp.Skia.Gtk, which successfully opened the window I expected to see.
Run dotnet run from within uapp.Wasm, which resulted in the error described above.
Look on the documentation for clues on why the file might not be found on a fresh template that's not been modified (I could not find anything)
Question:
What should I be doing differently to get the Web Assembly to build and display the app correctly?
EDIT: The file in the error does exist, precisely in the path in the error.
You're hitting an error that may happen when building with some native components, like SQLite or Skia.
To fix this, you'll need to execute the dotnet-setup.sh installation script which is not yet run automatically.
This script installs .NET Core, mono and ninja, on ubuntu-alike systems.
I have a Java 9 app that I'm trying to package for the Windows Store. The strange thing is that it works as expected when I run the exe-launcher directly, but I get the following strange error when I run the launcher via the APPX package:
Exception in thread "Swing-Shell" java.lang.InternalError: Could not
initialize COM: HRESULT=0x80010106
at java.desktop/sun.awt.shell.Win32ShellFolderManager2.initializeCom(Native Method)
at java.desktop/sun.awt.shell.Win32ShellFolderManager2$ComInvoker$1.run(Unknown Source at java.base/java.lang.Thread.run(Unknown Source)
HRESULT=0x80010106 means RPC_E_CHANGED_MODE which I guess means that COM is somehow already initialized in MTA mode. But why is this only an issue in the Windows Bridge sandbox? Does the Windows Bridge somehow pre-initialize COM somehow for some reason?
I'm not sure if this is a Java 9 issue, or a Desktop Bridge issue, or both. Does anybody have any ideas on how to identify the cause of the issue or workaround?
I have made a minimal Sample Project to reproduce the issue
The application works when executed directly, but not when executed via the APPX launcher. Why?
Analysis
The JDK parts, that rely on COM being initialized (D3DPipeline, Sound and windows shellfolder access) all follow the same pattern:
the run the code in a separate thread
for this thread CoInitialize is called
at the end of the user level code CoUnitialize is called
This is in line with the documentation the MSDN holds for COM and the analysis is correct, the error indicates, that the COM subsystem is already initialized to be MTA threaded.
So I modified the java launcher (jvm.dll) and inserted
debugging statements into some of the native methods in os_windows.cpp.
I focused on the threading methods. What I found was this:
create_main_thread, create_os_thread, pd_start_thread all
run with COM not yet initialized
the native thread initializer (thread_native_entry) is already
running with COM initialized
I looked more into in _beginthreadex and indeed I finally found a lead
on stackoverflow. That pointed me to the sourcecode of threadex.c,
which is part of the Visual Studio 2013 Express Installation.
There you find, that _beginthreadex does not directly start the
supplied thread function, but runs a library initializer
(_threadstartex) first. Part of this initializer reads:
_ptd->_initapartment = __crtIsPackagedApp();
if (_ptd->_initapartment)
{
_ptd->_initapartment = _initMTAoncurrentthread();
}
_callthreadstartex();
_crtIsPackagedApp detects via a kernel function if the application is
run as a "PackagedApp" (i.e. AppX package) and if so, then the
RoInitialize function is called, which from my understanding acts like the big
brother of CoInitialize.
Long story short: If your application is build with Visual Studio 2013
and run as a packaged application, you get a broken environment.
It was confirmed, that the working versions of the Oracle JDK were build with VS2010 SP1 and the broken version was build with VS2013SP4.
Workaround
With the above information google finally found a reference, that supports the analysis:
https://blogs.msdn.microsoft.com/vcblog/2016/07/07/using-visual-c-runtime-in-centennial-project/
Quote from that article:
Note that the existing VC++ 12.0 libraries created during the
Windows 8 timeframe have runtime checks to determine whether the
app is running under the app container or not. When running
desktop apps as a packaged app, these checks might limit the
functionality of the desktop app or cause it to behave like a UWA
(Universal Windows Application) (limited file system access or
create thread initializing MTA etc.). We have fixed this behavior
in the VC++ libraries contained in these framework packages and
thus removing the modern app limitations from your desktop
applications.
So I see to options to fix applications, that shall be distributed as AppX packages:
either force the users to have the updates VC++ 12.0 binaries installed (by introducing the dependency cited in the blog post) or
replace the msvcr120.dll that is bundled with Java 9 (and I assume also Java 10) with the fixed version from the update packages
I would go with the second version and I tested this. Starting with a clean up-to-date Windows 10 System, I installed JDK 9.0.4, I cloned the supplied testcase, modified it use the locally installed JRE (not the JDK!) and build the appx package. Running this, I reproduced the problem. I then replaced the msvcr120.dll's in the JRE folder of my systems installation with the one contained in the APPX container from:
https://www.microsoft.com/en-us/download/details.aspx?id=53176
Hint: *.appx are just ZIP files with additional signatures, so you can
just rename them and extract the contents.
I rebuild the testcase and it is working as it should (no COM
initialization errors anymore).
I am trying to install Oracle 12c instant 32-bit client alongside my 64-bit installation because I can't connect Visual Studio to the 64-bit version (throws BadImageFormatException). I run the installer and give it another directory for home, so it's like this:
64-bit: D:\app\MyUser\product\12.1.0\dbhome_1 (previously installed)
32-bit: D:\app\Lazar\product\12.1.0\dbhome_x84
The installer performs the checks and sends me to next step. I click install and it crashes!
Can someone please help?
I've actually run into the same problem. It looks like it is some sort of issue with the registry.
It appears to be a missing registry entry for the location of the Oracle Inventory. The below blog explains the following steps to add the missing registry key:
Open regedit
Go to HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node
Create a new key with name "Oracle"
Go to Oracle and then create a new String Value with name "inst_loc"
Give the value as "C:\Program Files (x86)\Oracle\Inventory"
Retry installation
This blog post has more detail on the fix (though not much) and is where I originally found my solution.
https://oracledba1949.wordpress.com/2016/03/11/oracle-12-1-0-2-32bit-client-installation-on-windows-2012-x64bit/
I also had the same issue and finally realized that Oracle installer doesn't support both 64bit and 32bit versions alongside. At least as you have mentioned in the question, it has got a bug. Here how I resolved the problem.
Hence both 64bit & 32bit versions unable to install alongside, first, uninstall the 64bit version.
Run the command %ORACLE_HOME%\deinstall\deinstall.bat
If any errors occur while uninstall, refer to the log and correct accordingly.
Recommend to restart the computer.
Install the 32bit version.
This will resolve your problem.
Many applications have this functionality now, but a good example is the Spotify client.
The app discovers there is a new version available, downloads it in the background then prompts the user to restart to get the new version. When the user quits the new version is installed (or the installed version is patched) then the application is restarted, all without further user interaction. In fact, the user really doesn't even have to do anything the app would automatically update on every exit if the user was never notified.
We have a cross-platform Qt 5.3 application and our lean startup business model requires us to push application updates very often so I'd really like to find a method that works cross platform with as little platform specific code as possible.
There are multiple parts to this question.
Noticing the update, and downloading the installer. (Obvious, and not a problem)
Running the installer application. Not an issue except how does one gain privilege? Spotify never asks for privilage to install again after the first install.
Avoiding "This application has been downloaded from the Internet" approval dialogue on every update.
Restarting the application after upgrading, but only when the user responded to the quit and upgrade prompt.
Specifically are there any tools, installers or code examples that do this?
You can follow how Google Chrome and Opera (latest one, not version <= 12) do it, rougly as below:
When installing the application, create a scheduled task that runs an updater as administrator (or a user with permission to write files to your application directory) periodically. For example in Windows, you can find GoogleUpdateTaskMachineCore and GoogleUpdateTaskMachineUA entries in Task Scheduler.
Your application structure looks something like the following (Google Chrome has similar structure in C:\Program Files (x86)\Google\Chrome\Application):
C:\Program Files\AwesomeApp\launcher.exe
C:\Program Files\AwesomeApp\1.0\AwesomeApp.exe ; version 1.0 of application
C:\Program Files\AwesomeApp\1.2\AwesomeApp.exe ; version 1.2 of application
The application shortcut created by installer will run launcher.exe. This launcher.exe will run the latest version of AwesomeApp.exe available in the directory. For example in the above structure, launcher.exe will run AwesomeApp\1.2\AwesomeApp.exe.
When the updater finds an update, it will download it and add the new version to the directory in the background. After that it will tell the running application (if it is running) to notify the user that an update is ready and can be used by restarting the application. And of course your older application needs to close itself and restart by running launcher.exe too. This updater may delete old application versions and keep only the latest two versions.
I previously installed a website on the server by running an msi package and everything worked fine. Now, when I try to run the same msi file (to Repair/Uninstall), I get a message:
When I click Cancel, I get the following message:
Anybody has an idea what happened and how it can be fixed?
I would recommend that you run the MSI with logging enabled. This can be done by using the /l*v C:\mylog.txt switch or by modifying the registry. The log will provide you with more precise information as to what is going wrong during the msi process.
The articles below describe how to enable logging and the logging process in more detail
http://support.microsoft.com/kb/223300
http://technet.microsoft.com/en-us/library/cc759262(v=WS.10).aspx
http://msdn.microsoft.com/en-us/library/aa372847(v=vs.85).aspx
Once you have the log you can use a set of MSI tools like the Orca installer database editor tool on the Windows SDK to correct any issues.
This is the link for Windows 7 SDK which contains the msi tools.
http://www.microsoft.com/en-us/download/details.aspx?id=8279
Sorry for answering my own question, but I found the problem and I want to share the solution:
After I installed the old version on the server, I changed the name of the msi file. Consequently, I could not run the old version to repair/update. I could not even install a newer version over the old version, as the installer needed the old msi to uninstall the old version.
When I changed back the filename of the old version, it allowed me to install the new version.
CONCLUSION: Don't change the name of the msi file after installation.