I am developing a project using VS2013 that will target WP8, WinRT & Windows Desktop platforms on x86 or x64 architectures.
This project requires local data access / storage and I have selected SQLite.
I wonder if anyone can point me towards resources / blogs / samples that will show me how to create a data layer that will allow me to target all of the above while still keeping as much of a common code base as possible for my data layer?
I have the vsix extensions for each of the SQLite "flavors" and also the C# wrapper, System.Data.SQLite.
Many thanks in advance,
Richard
You are going to have to create a Portable Class Library that can be used by all of those platforms.
In that Portable Class Library, you will need to use an interface and you will have to pass in the platform-specific implementations (WP8 and WindowsRT will require slightly different implementations).
But here is what helped me. There may be some other resources, but this was definitely the best one and the one that allowed me to do exactly what you are looking to do.
It's a series that I followed (and made a few changes along the way) but it helped me immensely.
http://nicksnettravels.builttoroam.com/post/2013/06/02/Windows-(RT-and-Phone)-and-Sqlite-(Part-1).aspx
Here are some snippets from Part 4 the series:
create a separate SQLitePCL project and to define a set of interfaces
which map to the classes/methods which is exposed by Sqlite-net. I’m
not going to bore you with the details but you can see from following
image just a couple of the interfaces which will map to classes such
as the SQliteConnection, TableMapping and Column.
Regarding the Platform implementations:
For each platform we need to implement these interfaces. This is
really a matter of taking the sqlite-net classes, defined in SQLite.cs
and SQliteAsync.cs and modifying them to implement the defined
interfaces. This isn’t quite as simple as adjusting the class
signature to include the appropriate interface but it isn’t far off.
We need to create a separate class library for each platform, eg
SQLiteWinRT and SQLiteWP8. It doesn’t matter which platform you start
with (I did the phone implementation first) since you’ll be
referencing the same classes using the “add as link” technique
discussed in the previous post. You might be thinking, if we’re simply
going to be adding the same classes to both libraries why they can’t
be all in the shared PCL. The answer lies in the conditional
compilation statements at the top of the sqlite-net files – these
determine how the classes are built for the respective platforms.
Related
I would like my application to benefit from a common data scheme to facilitate analytics and integration with other systems (Power BI and Dynamics come to mind). I have found the Common Data Model (CDM) Schema by Microsoft and want to understand better how this is used in practice with a .Net application. The "How to" information published by Microsoft seems to focus on Power Apps, but not how an implementation would look like for other frameworks.
On the Github page I have found resources for C# projects, which includes object interfaces (not specific entity interfaces as far as I can tell) and some tooling (adapters and tests).
In addition, in the Microsoft documentation I have found definitions of the entities.
Now I would like to understand the best way to benefit from the CDM schema:
Do I write my own classes/entities of which the properties are in line with the linked documentation on what entities should look like? Or are these entities available as classes in a Microsoft supplied namespace?
a) If I write my own classes, can I pick and choose which properties I implement? Or can I only benefit from common functionality when I implement 100% of the listed properties? b) How do I support properties outside the ones defined by Microsoft and still have these properties work outside my application?
c) If I can skip properties, will functionality outside my application (PowerBi etc) fail softly when expected properties are not available?
It's not obvious to me which interfaces (as supplied on Github) need to be implemented for which entities (as listed in the Microsoft hosted documentation), how do I know what to implement for which entity?
I would be very happy if anyone can supply any relevant resources (.Net related?) outside the two I listed, as I am not able to find much on this topic.
I am creating a class diagram in Visual Paradigm and I am struggling with one thing. How do I specify that a class is in fact a form. So when I export the diagram to code, it wont become a normal class but instead it will become a form. A form which can hold buttons, ListBoxes, etc.
Thank you!
You intend to specify in your Visual Paradigm (VP) diagram a dependency on Form which is a class available in the .NET framework.
It seems there is no clear explanation how to do that specific operation in the VP documentation. However, there is an article that covers the topic with Java SE classes. This article uses the Java platform sources (available as a zip file in the JDK since Java 6) to extract the classes in a specific project. Then the reversed project is registered as a referenced project in your model project.
It seems this is possible to do a similar operation with .NET dlls instead of Java sources (have a look at the linked article - the screenshot for step 2). For that you have to identify the relevant dll(s) in your environment: I guess the Microsoft .NET framework, not Mono. According to a Microsoft documentation, the appropriate file would be something like System.Windows.Forms.dll. You should be able to find that file in your environment. On the identification of the relevant dll(s), I can't help you further (being myself a Java developer working on Linux).
Beware: your library project should be quite important as you will have all the dll classes represented. This is probably the reason why the documentation makes the reversal in a separated project and not in the real model project (another reason could be the possibility to use the classes in other projects).
I have a class library that targets .net 4 and is used across different platforms via Mono.
I now want to port it to be used by Windows 8. I know the name keeps changing but this is currently called a "Class Library (Windows Store Apps)" in VS2012.
I initially started with trying to port everything to a "Portable Class Library" but this was proving too difficult as some things simply didn't have a generic approach that would work on all platforms targeted, and other things that were supported simply weren't available to the compiler.
So I've created a Windows Store Class Library and created links to the existing files of my standard Class Library so updating once will update both. I am planning on using pre-processing directives to make changes between the two class libraries
E.G
#if NETFX_CORE
Task.Delay(someTime);
#else
new System.Threading.ManualResetEvent(false).WaitOne(sometime);
#endif
My question is if this method seems a sensible approach? I have the same default namespace and assembly name. Could this ever cause issues to my compiler? The assemblies target different platforms so would never be used together in the same application but do both sit in the same solution in Visual Studio.
Overall, yes that should work. That specific case is a poor example, because the two implementations function very differently, illustrating that you may need to rethink some aspects of your design. For cases where there is a similar API swap (with similar semantics), I personally tend to move the difference behind a helper method, so my "main" code doesn't need to worry about this - just the helper code. Reflection would be a good example of this (the changes to reflection are annoyingly deep).
The two projects with different target platforms should be fine. I occasionally hit an IDE glitch where it complains about temp files. I think this is due to sharing files between projects. I've logged it on connect
Try
Task.Delay(msDelay).Wait()
I've gotten to the point where I have made a few classes that I have found to be rather useful for a variety of different projects, they're either extensions of the already existing .Net ones or something entirely new.
Although I may not use them for EVERY project I would most certainly use them again at some point, my questions is what is the best way to keep these stored?
I was thinking about compiling them into a .dll that I can simply reference if necessary but at the moment there are only about 4 different classes, I've always thought that a .dll is more suited towards a larger amount of classes.
Would it just be simpler to store them somewhere in the cloud so I can access them from pretty much any computer?
What has worked best for you?
Edit: I'll be using more than one computer as I sometimes use the university computer facilities.
The classes range from memory management helper classes in XNA to niche functions in regular .Net/C#
If the classes don't fit together naturally as an assembly, keep the source files somewhere like Github and include them in your projects where needed. You can always rearrange them into components at a later date, when you feel it's worthwhile.
Are these classes in any way related? If you want to use one of them, do you need the others? If not, then those don't belong in a common package together.
Robert C. Martin provides some decent introduction in the chapter "Principles of Package and Component Design" of his book "Agile Software Development". There is also a C# adapted version with very similar content called "Agile Principles, Patterns and Practices in C#".
What I'm just saying is, packaging components is not only about thinking components X and Y are "cool enough" to be reused, but also about how you organize things and how well libraries or packages fit into the big picture.
You could compile them as a DLL and install them to the GAC. Then you can reference the DLLs from any project you need, just like any native C# library.
And I agree with Jim Brissom. Compile only the classes that go together as one assembly.
I keep my common classes in sourcegear and then share them into any projects as required.
I'm starting a new project which would greatly benefit from program add-ons. The program in its most basic form reads data from a serial port and parses it into database records. Examples of add-ons that could be written would be an auto-archive add-on, an add-on to filter records, etc. I'm writing both the program and the add-ons, but some customers need custom solutions, so instead of branching off and making a completely separate program, add-ons would be great. The simplest add-on would probably be a form who's constructor takes an object reference, manipulates the object in some way, then closes.
Unfortunately, I have absolutely no idea where to start coding, and almost as little idea where to search. Everything I search for turns up browser add-ons. From what I have gathered, I need to look into dynamic loading DLLs. Besides that, I'm clueless. Does anyone have any good resources or examples I that they know of?
I'm happy to provide more details, but this project is in its inception, so I don't have a ton of specific details (specifics kind of defeats the point of add-ons, too.)
You should seriously consider using the Managed Extensibility Framework (MEF) to handle your plugin architecture. It requires thinking about things a little differently, but it is well worth the mind-stretch.
This is a simple example to illustrate the basic technique.
codeproject.com - Plugin Architecture using C#
This article demonstrates to you how
to incorporate ... as a
plugin for another application or use
it as a standalone application.
in .NET 4 you now have the Managed Extensibility Framework (MEF) to do much of the plumbing.
In .NET 3.5 you had the System.AddIn but it was deemed by many to be far too complex.
codeproject.com - AddIn Enabled Applications with System.AddIn
AddIns (sometimes called Plugins) are
seperately compiled components that an
application can locate, load and make
use of at runtime (dynamically). An
application that has been designed to
use AddIns can be enhanced (by
developing more AddIns) without the
need for the orginal application to be
modified or recompiled and tested
You really need to look at Managed Extensibility Framework (MEF). This is specifically designed to help support add-ons and other extensibility.
A very basic description (basically, your plugins must implement a special interface):
http://martinfowler.com/eaaCatalog/plugin.html
Much better article, in C#:
http://www.drdobbs.com/184403942;jsessionid=TVLM2PGYFZZB1QE1GHPCKHWATMY32JVN
I think Reflection will play a major role.
I expirimented with an app that had a plugin folder. A filesystem watcher would watch the folder, and when a new DLL was placed in it, it would use reflection to determine which types of plugins it included, loaded them, and added them to the list of available classes, etc.
Try using the term 'add-in' or 'plug-in' for your research instead of 'add-on'. That should help some.
If you're using .Net 4, there's an add-in namespace in the framework that will get you partway there.
Writing plug-in support for an app is no simple task. You'll have to maintain pretty strict separation-of-concerns across your interfaces, you'll need to provide an interop library that defines ALL of the supported plug-in types, and you'll want to do some research into dependency injection & inversion of control, in addition to the previously-suggested reflection research.
It sounds like you might have a busy weekend doing research.