Unity and Firebase - Package Manager Resolver, uninstalling the following packages: Firebase Authentication - firebase

I'm using Unity 2019.3.4f1 and Firebase Package 6.15.2 and when I import the Custom Package the Package Manager Resolver asks to change the "/manifest.json".
When I click "Add Selected Registries", Unity starts to Uninstall the packages and stay on its hours with this message: "Uninstalling the following packages: Firebase Authentication"
Package Manager Resolver
I can't deploy or play the game without this message appears.

What you're running into is that newer versions of Unity support a package manager that makes it easier to install and manage dependencies. Newer versions of the Firebase SDK can optionally take advantage of this.
I can't quite tell what your specific issue is, but there are a couple routes forward.
The simplest is to just click "Disable Registry Edition." If you don't feel like messing with this system at all, just click this button and work with Unity packages as you're probably expecting.
Otherwise, you can click "Add Selected Registries." This will kick off a somewhat complex process where:
The Firebase plugin adds a "Scoped Registry" to Unity (this is that code you see in the "After" pane). This tells Unity about Google's package repository.
The Plugin then looks for any package that is included in the registry and uninstalls it to avoid having it included twice.
The Plugin adds the package it uninstalled to your package manifest. This lets you maintain and update the Firebase plugin right in Unity with the "Package Manager" window:
There are plenty of reasons why you'd want to do this. First, the Firebase Unity SDK is HUGE on disk -- much larger than the SDK is even in your project. The reason is that it has redundant copies of every Firebase library for both legacy .NET3 projects and for modern .NET4 projects. Each unitypackage also has to include all of its dependencies -- that means that FirebaseCore is redundantly included in every unitypackage.
Second, what gets me the most, is that the Firebase plugin is too big to fit into a GitHub repo without Git LFS. This is because one or more of the libraries needed to support Linux is larger than a single source file can be. When you use the package manager, this stuff is kept out of your source repository (if you don't commit the Library/ directory, which you shouldn't) keeping your size in the cloud down and making this workaround unnecessary.
Third, as illustrated in the screenshot I included above, it's just easier to upgrade and downgrade the Firebase SDK as needed when you use the package manager. You no longer have to try to remember which Firebase libraries you've installed, you can see them in a neat list! You can also easily uninstall Firebase features that you don't need without worrying too much about large dependencies laying around (you still have to manually clean up some native plugins).
You can also perform all of this manually! Instead of downloading the Unity SDK, you can manually perform the steps as outlined here. Namely you can add:
"scopedRegistries": [
{
"name": "Game Package Registry by Google",
"url": "https://unityregistry-pa.googleapis.com",
"scopes": [
"com.google"
]
}
]
to the end of your Packages/manifest.json as indicated in that popup window. Then install and manage the Firebase plugin that way without worrying about migration at all.
EDIT:
I also should mention that if you do think that you're running into a bug, the system responsible for the dialog you're seeing is known as the "External Dependency Manager for Unity." You can file issues directly on its GitHub page.

Related

Crashlytics could not find the resource file generated by Google Services

Crashlytics could not find the resource file generated by Google Services.You may need to execute the :processGoogleServices Task
i read the solution from this qusetion Crashlytics could not find the resource file generated by Google Services. You may need to execute the :process<Variant>GoogleServices Task
but i didn't succeded to run this command in my unity project
./gradlew :app:processProdReleaseGoogleServices or ./gradlew :app:processDevReleaseGoogleServices
how can i run it?
A tricky bit with the Unity SDK is that because Firebase still supports versions of Unity that predate a total move to gradle (I believe 2019.4 is when Unity switched over entirely, the earliest supported version right now is 2017.4), many Android specific solutions (such as the one you linked) won't function. If you did want to try it, you can select "Export Project" in your build settings -- but I don't think this will help:
It sounds instead like you're missing Plugins/Android/FirebaseApp.androidlib or Plugins/Android/FirebaseCrashlytics.androidlib. These are generated by the Firebase plugins (obviously FirebaseCrashlytics.androidlib is specific to Crashlytics -- you won't see that one otherwise) as part of a processing step to simulate what the Play Services gradle plugin would do in a typical Android application or game.
Some things to try:
Make sure you're on a supported version of Unity (2017.4 or newer -- Firebase does not officially support alphas or betas).
Ensure that you have a valid google-services.json file added and that Crashlytics has been added to your backend (full instructions here to redownload).
Re-add FirebaseCrashlytics and ensure that you leave everything checked.
Ensure that you have the latest Crashlytics plugin (currently 7.1.0). You can download just Crashlytics now from this site, but make sure you don't mix and match versions with other Firebase plugins.
And if none of these work, sometimes small changes in build environments expose unexpected issues. Your best bet will be to file an issue here with everything you've tried.

Artifactory - Concept of File Versions

I'm currently starting with JFrog Artifactory. Up to now I have only been working with source code control systems not with binary repositories.
Can someone please tell how the versioning of files is done in Artifactory?
I have been trying to deploy a file, then change it and deploy it again.
The checksum has changed, so it's the new file. But it seems that the old version is gone.
So it looks like there are no version of files. If I want that do I have to do it in the filename?
I found versions related to packages.
But I was thinking to use it for other files as well.
Thanks for your help
Christoph
Artifactory, unlike a VCS system, is not managing a history of versions for a given path. When you deploy an artifacts over an existing artifact, it will overwrite it (you can block this by configuring the right permissions).
If you wish to manage permission for generic artifacts (ones which are not managed by a known package manager like npm, Maven etc.), there are a couple of options you can take:
Add the version as part of the artifact name, for example foo-1.0.0.zip
Add the version as part of the artifact path, for example /foo/1.0.0/foo.zip
Combine the 2 above approaches, for example /foo/1.0.0/foo-1.0.0.zip
Use an existing package management tool which is flexible enough to handle generic packages. Many people are using Maven to manage all types of packages beyond Java ones (it comes with its pros and cons)
From the Artifactory point of view there are a couple of capabilities you can leverage:
Generic repositories - aimed at managing proprietary packages which are not managed by a known package manager
Custom repository layout - can be used to define a custom layout for your generic repository and assist with tasks like automatic snapshot version cleanup
Properties - can be used to add version (and other) metadata to your artifacts which can used for searching, querying,resolution and more
Lastly, Conan is another option you should consider. Conan is a package manager intended for C and C++ packages. It is natively supported in Artifactory and can give you a more complete solution for managing your C libraries.

GUID error after I import External Dependencies Manager (EDM) and Firebase Core from Package Manager

I'm new to Google Firebase and wanted to do some sample app.
But after import External Dependencies Manager (EDM) and Firebase Core from Package Manager, it gave me GUID errors, example the image below.
Error log
I do hope Firebase or Unity3d expert able to help me with this.
I'm using Unity3d 2019.3.13f1 and Firebase SDK 6.14.
It looks like you may have run into an issue similar to this one. If you installed via a UnityPackage and said "yes" to installing EDM4U:
You'll want to double check that you've followed the instructions here.
To summarize:
EDM4U provides a tool to uninstall managed packages which is accessible using the Assets > External Dependency Manager > Version Handler > Uninstall Managed Packages menu option. Select all Firebase SDKs as well as External Dependency Manager and click Uninstall Selected Packages.
Alternatively you can also remove the SDK manually from Assets folder.
So if you've installed the package repositories, you'll want to make sure that you remove from your Assets folder:
Firebase
Parse
PlayServicesResolver
ExternalDependencyManager
Editor Default Resources/Firebase
Plugins/Android/Firebase
Plugins/iOS/Firebase
Alternatively, if Unity Package Manager integration isn't for you, you can remove the installed registries:
You may want to re-install the Unity Package afterwards as well in case they'd been partially uninstalled.
This is a bit of a shot in the dark, but I hope it helps!
--Patrick

STS: Losing references in Java Build Path

I am using Spring Source Tool Suite 2.8.1 to implement Spring applications.
I frequently get build errors because references are lost for no apparent reason. In Right-click project in Package Explorer->Properties->Java Build Path->Order and Export, I find projects sometimes are deselected. And often packages are gone in Right-click project in Package Explorer->Properties->Java Build Path->Deployment Assembly.
Having to reset these settings frequently is frustrating. Is there some way I can work around these problems?
I have tried to update STS to the latest version, but the upgrade process fails with incomprehensible error messages. I want to avoid a clean install because setting up the environment again would probably be a nightmare.
Now that I know this is a maven project and you are adding references yourself, this is making sense to me. STS 2.8.x was the last STS to ship with the legacy m2e (maven plugin for Eclipse). It did not recognize build path entries added manually (it likes to have complete control over the classpath). So, what is likely happening is that you are adding these classpath entries and then an update project operation gets kicked off automatically. This will have the effect of removing all of your extra classpath entries.
You are best off doing the following:
Updgrading STS
Or just upgrading your m2e component (you will have to first uninstall the old m2e, but this should be taken care of automatically from the discovery update page).
Or, just accept the fact that you can't manually change your classpath with the legacy m2e.

Manually re-creating an install profile

I've been reading about drupal install profiles, and I'm wondering if there's much of a difference between using a packaged install profile vs. installing core + manually installing the modules listed in the install profiles?
I'd like to do the latter (manually installing each) to control the versions of each module installed, which I can't control with a packaged install profile that may not have been maintained.
But should I or will I be opening the door to something I'm not aware of? Shouldn't the 2 be identical, just one automated and other is manual?
What kiamlaluno said, plus the fact that installation profiles may perform custom configuration of settings on install, might construct custom views/content-types/etc (especially by means of features.module, which you can see heavy use of in OpenAtrium), and might provide other custom code in distro-specific module.
The short answer is, no you can't just replicate an install profile by downloading a clean drupal with all those modules -- best bet is to use the install profile. If you're worried about module versions, just make sure you're using a profile that's actively maintained.
The difference is that an installation profile includes the right version of all the modules it needs.
This means that differently from manually installing each module, you don't need to verify the correct version of the module X that effectively works together the module Y; there are few cases where one module doesn't work well when version A of another module is installed, and you need to install version B of the same module, if you don't want problems.
An installation profile can have a custom installation page that allows you to change some parameters of your site; it also allows the installation profile author to define a patch that needs to be applied a module, in order to fix a bug of the module, or to make it work better with another module.
If you need to set a site to work for a particular purpose, installation profiles are useful for you as they allow you to set the site correctly without to know all the details about how a Drupal site needs to be set.
I believe you can specify the versions of the modules you want to install see

Resources