The Problem is that this:
var database = new Database(“my-database”);
brings me a infinity loop with UWP. The same Code without Couchbase.Lite.Support.UWP.Activate(); with WPF works.
The Breakpoint on this line comes on but the next line is never executed.
Database = new Database(“A”);
// Never executed in UWP
var newTask = new Document();
newTask.Set(“type”, “task”);
newTask.Set(“owner”, “todo”);
newTask.Set(“createdAt”, DateTimeOffset.UtcNow);
Database.Save(newTask);
And i get no Errors, any Ideas?
I use couchbase.Lite.Support.UWP Version 2.0.0-dp012
Without the activate call that code should throw an exception because it can’t resolve the default directory without support classes. If this happened all the time it would have quickly shown in our automated testing so it makes me think it is an environmental issue. Can you get a deeper stack trace? There is a symbol server set up at http://mobile.nuget.couchbase.com/symbols/Developer that you can get symbols from.
Thanks for the symbols.
I get System.TypeInitializationException occurred HResult=0x80131534 Message=The type initializer for 'Couchbase.Lite.Database' threw an exception. Source=<Cannot evaluate the exception source> StackTrace: at Couchbase.Lite.Database..ctor(String name) at Training.Core.CoreApp.OpenDatabase(String dbName, String key, String newKey) in D:\Arbeit\Xamarin\mobile-training-todo-feature-2.0\dotnet\Training.Core\CoreApp.cs:line 123 at Training.Core.CoreApp.StartSession(String username, String password, String newPassword) in D:\Arbeit\Xamarin\mobile-training-todo-feature-2.0\dotnet\Training.Core\CoreApp.cs:line 84 at Training.Core.CoreAppStart.Start(Object hint) in D:\Arbeit\Xamarin\mobile-training-todo-feature-2.0\dotnet\Training.Core\CoreApp.cs:line 265 at Training.UWP.App.OnLaunched(LaunchActivatedEventArgs e) in D:\Arbeit\Xamarin\mobile-training-todo-feature-2.0\dotnet\Training.UWP\App.xaml.cs:line 124*
I will google that a little, i think i miss something important in the docs
You mean you get that when you DONT call activate right? That’s what I would expect. If you want to keep going without activate you can use the other db constructor that takes a directory to put the database in but that’s a hack
With the symbols you should be able to step into almost anything as the source is included in the Nuget package. I messed up db012 so the actual activate call has no symbols I think but the rest should.
I’m also having the same problem and the problem appears also in the developer build 11 & 13. In developer build 10, there is no such a problem.
I also tried to use the other constructor without activating support library as following.
var config = new DatabaseConfiguration()
{
Directory = ApplicationData.Current.LocalFolder.Path
};
var database = new Database("mydb", config);
But I got the following exception.
A required dependency injection class is missing.Please ensure that you have called the proper Activate() class in the support assembly (e.g. Couchbase.Lite.Support.UWP.Activate()) or that you have manually registered dependencies via the Couchbase.Lite.DI.Service class.
Then I registered some services before creating DB like as following.
Service.RegisterServices(collection =>
{
collection.AddSingleton<ILoggerProvider>(provider => new LoggerProvider());
collection.AddSingleton<IDefaultDirectoryResolver, DefaultDirectoryResolver>();
});
I also implemented LoggerProvider and DefaultDirectoryResolver classes with very basic content, just to make the code work.
The exception solved but the DB does not work properly.
I think I should not go by this way, I need to activate UWP support but I can’t get any details about why the code does not continue to execution. Also, I have no access to symbol server setup link that you shared so that it seems currently it is not possible to get any detail regarding to this issue for me.
You won’t have access by directly pointing it into your browser, you need to set up symbol server inside of Visual Studio so that it will pull and use the symbols when you run inside the debugger.
One thing about UWP is that it doesn’t always update the dependency packages when updating the main package which I find incredibly irritating. One thing to confirm is that both your versions of Couchbase.Lite and Couchbase.Lite.Support.UWP are the same DB. I’ll consider changing the nuspec to use a hard equal dependency to see if that helps (double check the actual references in your csproj too to ensure they are pointing at the right library)
EDIT Also see if you can find any logs in your app package directory in the Logs folder. That should explain more things, unless the logger is failing to register.
I’ve checked Couchbase.Lite and Couchbase.Lite.Support.UWP versions and both versions are the same. Also, the log file in the logs folder in app package directory is empty. I will try to set up symbol server.
I’ve added symbol server set up URL to Visual Studio as a Symbol file (.pdb) location then it pulled Couchbase.Lite.pdb and Couchbase.Lite.Support.UWP.pdb files but nothing changed. The code still stuck in infinite loop and does not give any detail.
Did you run in a debugger and pause while it is stuck to see exactly where it is stuck? What I’m looking for is a stack trace beyond that line. I imagine if either of the constructors threw an unhandled exception that it wouldn’t stick like that. If you notice a stack ending in a class called Native then I’d encourage you to turn on Mixed Mode Debugging since UWP is good at giving stack traces between managed and native.
EDIT Furthermore you should be able to now step inside the library source as if you compiled it yourself. I tried this before and it worked nicely with .NET Core (I hope it’s the case with UWP).
I’m having the same problem since version 2.0.0-dp012. Currently I’m using dp013 and the problem is still around. Version dp011 was working fine.
I’ve been following this post and I tried to get the debug symbols to work in order to provide you with more information but the pdb and dll don’t match:
Well…I have no idea what that means really…I just add the PDB that gets generated during the build and that is the one that gets served up from the server. It didn’t complain about mismatch when I ran it in the debugger on my machine. I’ll try to see if anything big has changed since db011 but it is going to be just simple guessing.
P.S. I found the tool you mentioned and apparently it can fix the pdb file. If you fix the local one it should match until it gets deleted and I’m curious if the symbol source server I am using is messing with the PDB file (there was an open issue last year about it), but even though it is mismatched with age it is still working on my setup. I am currently having VPN troubles so I cannot connect to HQ to examine this further right now but I will pick this up again when that is resolved.
Fixing the local pdb unfortunately won’t work (different ages): ChkMatch is capable of making an executable and PDB file match if they have different signatures but the same age (see this article for more information about PDB signature and age).
Interestingly enough, I can load the symbols (even though the VS says you can’t with mismatching ages) but they aren’t used in debugging. No stepping, and no stopping.
I’ll leave this path for now and have a closer look at the changes from versions 11 to 13.
Same problem as m.wecker have. Only with UWP.
If I use Couchbase.Lite.Support.UWP.Activate(); in UWP project, everything hangs in core project on line Database database = new Database(“mydatabase”);.
My “solution” is to comment Activate() part, and just pass path from UWP to core: string path = Windows.Storage.ApplicationData.Current.LocalFolder.Path; LoadApplication(new MyNamespace.App(path));
and then create database with given path: DatabaseConfiguration config = new DatabaseConfiguration(); config.Directory = path; database = new Database(“mydatabase”, config);
Stepping is broken for a different reason it turns out. Symbols and source are two different things, and our source API endpoints are behind a firewall as I just discovered. I need to find someone who can open that up before it will work.
Many people seem to indicate that commenting out the Activate() portion lets the library continue…so I wonder if something is wrong with one of the DI classes. It’s super odd that this problem never shows up for me but shows up for so many other people…
My best guess right now is that the logger is locked for some reason. Perhaps try registering a custom logger after the activate call and see if that clear things up?
Same problem as m.wecker have. Only with UWP.
If I use Couchbase.Lite.Support.UWP.Activate(); in UWP project, everything hangs in core project on line Database database = new Database(“mydatabase”);.
My “solution” is to comment Activate() part, and just pass path from UWP to core:
string path = Windows.Storage.ApplicationData.Current.LocalFolder.Path;
LoadApplication(new MyNamespace.App(path));
and then create database with given path:
DatabaseConfiguration config = new DatabaseConfiguration();
config.Directory = path;
database = new Database(“mydatabase”, config);
After that, reading/writing/blobing works ok.
After your comment, I’ve checked this solution again and I noticed that the exception actually does not cause the crash.
From what I can see at first glance there are is one change in database.cs from 11 to 13 which might be responsible. There are a lot more changes but this one seems to be the most promising.
private static string DatabasePath(string name, string directory)
This one looks like a good candidate:
old:
return System.IO.Path.Combine(Directory(directory), $"{name}.{DBExtension}");
I have no idea what the problem is, but calls to the constructor new Database(myName, myDir) as well as Database.Exists(myName, myDir) do both call Database.Path() and lead to the described hang up … and UWP is really picky when it gets to file handling.
Just guesswork but the best I can come up with without symbols.
Some more digging has narrowed it down to a likely problem with the new DependencyInjection.
The easiest workaround is therefore indeed to use the database constructor in the UWP project directly, because DependencyInjection is simply not used then.
Couchbase.Lite.Support.UWP.Activate();
DatabaseConfiguration config = new DatabaseConfiguration() { Directory = ApplicationData.Current.LocalFolder.Path };
string dbName = myDBName;
Database db = new Database(dbName, config);
Activate() may still be called. Commenting out doesn’t seem to be necessary.
