Is there a PCL version of SqlCipher available?

595 views
Skip to first unread message

Michael Stuart

unread,
Mar 19, 2014, 5:37:43 PM3/19/14
to sqlc...@googlegroups.com
I'm interested in whether there is a PCL version of SqlCipher available, instead of having separate iOS and Android versions.  If not, are there any plans to have one?  Thanks!

Michael

Nick Parker

unread,
Mar 20, 2014, 9:52:31 AM3/20/14
to sqlc...@googlegroups.com
Hello Michael,

There is not a PCL version of SQLCipher on the Xamarin platform. They
need to remain separate due to their distinct compile time requirements.
> --
>
> ---
> You received this message because you are subscribed to the Google
> Groups "SQLCipher Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to sqlcipher+...@googlegroups.com
> <mailto:sqlcipher+...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

--
Nick Parker

signature.asc

Michael Stuart

unread,
Mar 21, 2014, 11:32:52 AM3/21/14
to sqlc...@googlegroups.com
Nick,
We are interested in having our model classes be in a separate PCL project, in order to share the models more easily.  Our issue is that the attributes you put on model classes are in SqlCipher, and iOS/Android need separate dll references.  If the SqlCipher attributes were in a separate PCL assembly, then it seems like it would allow customers to do this more easily, unless I am mistaken.  Do you have any suggestions for this?  Thanks!

Michael

Nick Parker

unread,
Mar 21, 2014, 11:54:56 AM3/21/14
to sqlc...@googlegroups.com
Hello Michael,

A possible solution may be to separate the custom attributes from the
sqlite-net project. Your model project would have a dependency on the
new attributes assembly which would be a PCL. sqlite-net would then
depend on the same attributes assembly for each specific platform
compilation (iOS and Android). Do you think this configuration would
work for your scenario?
> > an email to sqlcipher+...@googlegroups.com <javascript:>
> > <mailto:sqlcipher+...@googlegroups.com <javascript:>>.
> > For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
> --
> Nick Parker
signature.asc

Michael Stuart

unread,
Mar 21, 2014, 12:02:54 PM3/21/14
to sqlc...@googlegroups.com
Yes, that sounds like what I am talking about.  I just don't understand if this separate PCL containing the sqlite-net attributes is something I would do myself, or if the SqlCipher assembly would need to actually reference the attributes in this new PCL (and require a new Sqlcipher build).  If this should work fully outside of any Sqlcipher changes, I will give it a shot.

Nick Parker

unread,
Mar 21, 2014, 5:41:23 PM3/21/14
to sqlc...@googlegroups.com
Hello Michael,

This type of change would require changes in the way we prepare and
package SQLCipher for Xamarin. We are about to perform additional work
on SQLCipher for Xamarin in the near future, so we will take a look at
if and how we might allow for this type of customization. Thanks!
signature.asc

Michael Stuart

unread,
Mar 24, 2014, 9:41:01 AM3/24/14
to sqlc...@googlegroups.com
We will keep an eye out on the future releases.  Thanks for your response!

Nate Rickard

unread,
May 1, 2014, 1:43:46 PM5/1/14
to sqlc...@googlegroups.com
Hi Nick,

Just wanted to send a quick +1 to this request.  We absolutely need to be using SQLCipher but due to the architecture of our latest mobile projects using PCLs, etc., it's not possible.

We use the SQLite.Net and SQLite.Net.Async PCL packages from NuGet and have a shared PCL that is used from Android and iOS projects.  This is where all of the business logic and data access occurs for our projects, so SQLCipher being platform specific makes it a non-starter for us.

You should be able to use the same model as the SQLite.Net project (https://github.com/oysteinkrog/SQLite.Net-PCL) where there is a PCL and then platform specific DLLs that are included and "registered" at startup to provide the actual lower level implementation.

I can only imagine this will become more common as PCLs continue to take off.  Please consider including this support in the next release.

Thanks!
Nate

Nick Parker

unread,
May 1, 2014, 4:42:21 PM5/1/14
to sqlc...@googlegroups.com
Hi Nate,

Thanks for sharing your input on the PCL discussion. This is something
we will consider in the future.

John Goodwin

unread,
May 8, 2014, 11:55:07 AM5/8/14
to sqlc...@googlegroups.com
Hi Nick,

I would also like to +1 this idea.  If the attributes are separated a PCL, it will make this project much more useful in being able to share models between projects and also addressing cross platform issues.

John

Michael Stuart

unread,
Jun 16, 2014, 4:32:05 PM6/16/14
to sqlc...@googlegroups.com
Nick,
I just wanted to see if you had any update on PCL support for SqlCipher.  More people are starting to use PCLs and universal projects these days to support multiple types of clients, but still share code.  Thanks!

Nick Parker

unread,
Jun 17, 2014, 10:13:43 AM6/17/14
to sqlc...@googlegroups.com
Hello Michael,

At this time we do not have anything to share with regard to PCL support
within SQLCipher. This continues to be an item we will investigate, but
is not something on the immediate roadmap.
signature.asc

Lee Olsen

unread,
Jan 28, 2015, 11:03:02 AM1/28/15
to sqlc...@googlegroups.com
+1 for PCL support as well.

Dan Lamppa

unread,
Mar 16, 2015, 4:21:48 PM3/16/15
to sqlc...@googlegroups.com
Nick's proposed idea is exactly what I am looking for: "... to separate the custom attributes from the sqlite-net project.  Your model project would have a dependency on the new attributes assembly which would be a PCL. sqlite-net would then depend on the same attributes assembly for each specific platform compilation (iOS and Android)."

Please let me know the status of this. Nick you mentioned last March: "This type of change would require changes in the way we prepare and package SQLCipher for Xamarin.  We are about to perform additional work in SQLCipher for Xamarin in the near future, so we will take a look at if and how we might allow for this type of customization"

As I understand it, we'd need the SQLite.net equivalent attributes and an Interface that the connection class implements in a PCL.

I am working with an Enterprise client who paid for SQLCipher but is not going to use it because of this issue. Instead this client is building a custom solution by encrypting select fields before storing the data in an unencrypted database.

We went through a great deal of trouble to separate shared code into a PCL library to share between platforms. Data is stored locally in SQLite using SQLite.net as the ORM. Later in the project we got the requirement to encrypt some of the data. I figured it would be easiest just to encrypt the entire database with SQLCipher. Unfortunately, we discovered we need to move the model classes into the platform specific projects (or a Shared project) to allow this to work. Since so much of the shared code depends on the model classes, we'd need to move most of the PCL into a Shared project. We don't want to move the entire PCL into a shared project. This is like a step backwards. Shared projects are quirky in Visual Studio probably since they are relatively new. PCL's have finally become stable and work well.

It's a common practice to put shared code in a PCL when creating Xamarin apps using MvvmCross or Xamarin.Forms. If the SQLite.net attributes and Interface was put in a PCL, it would allow a lot more Xamarin apps to use SQLCipher.

Note: If the SQLite implementation could somehow be "injected" into SQLite.net it would solve this issue elegantly. This would allow the implementation of SQLite vs SQLCipher to be interchanged without changing code that refers to SQLite.net. I am not sure if this is possible. If so it would require changes in SQLite.net also.

Thank You,

Dan


On Wednesday, March 19, 2014 at 4:37:43 PM UTC-5, Michael Stuart wrote:

Nick Parker

unread,
Mar 18, 2015, 8:54:48 AM3/18/15
to sqlc...@googlegroups.com
Hello Dan,

At this time we do not have a PCL version of SQLCipher for Xamarin.
This is certainly something we are considering for the future. Thank
you for your feedback.


Nick Parker
Reply all
Reply to author
Forward
0 new messages