I am trying to use the Caliburn.Micro framework.
However the first page of the documentation refers to a class that doesn't exist anywhere, called Bootstrapper.
Unlike other versions of Caliburn Micro the WinRT version doesn't use a Bootstrapper, the non ranty reason for this is that Windows.UI.Xaml.Application exposes most of it's functionality through method overrides and not events. Therefore it makes sense to have a custom Application rather than forcing the developer to wire the application to the bootstrapper.
This quote is taken from the documentation on Working with WinRT from the official wiki documentation.
You can look at the complete list of documentation wikis at the official site at Codeplex.
This is an issue with the WinRT version of Caliburn.Micro where there is no bootstrapper type.
I found this WinRT-specific tutorial that covers things:
Related
I found the WebSockets-Namespace in the .NET core documentation.
There is an abstract WebSocket class, I understand that I cannot instantiate this class directly, do I need to inherit the class and implement it by myself or is there a complete implementation somewhere else?
Link to documentation
I googled a lot, but everything I can find is for ASP.NET core.
Microsoft do provide a client implementation of the WebSocket class called ClientWebSocket.
You can find it as a NuGet package: System.Net.WebSockets.Client
As far as I know, this is the only official and available implementation. If you need more than this, I do believe you have to find a 3rd party library or implement it yourself.
Recently, Microsoft started with a new X-Tag library to create custom elements. The website says,
X-Tag is a Microsoft supported, open source, JavaScript library that wraps the W3C standard Web Components family of APIs to provide a compact, feature-rich interface for rapid component development. While X-Tag offers feature hooks for all Web Component APIs (Custom Elements, Shadow DOM, Templates, and HTML Imports), it only requires Custom Element support to operate. In the absence of native Custom Element support, X-Tag uses a set of polyfills shared with Google's Polymer framework. You can view our package options in the Builds section
As far as I remember, not so long ago, even Mozilla had a similar project with the exact same name X-Tag.
How are these projects different from each other? Or are they the same project with a renewed branding?
After some digging, I managed to find out a thread on reddit which confirms, that they are indeed the same project.
Infact, the original developer - Daniel used to work at Mozilla, when he created the X-Tag project but since then he has moved to Microsoft.
Hence, it is now a Microsoft-supported project founded by an x-Mozillian. Also confirmed on Twitter.
I'm using Caliburn micro with a WinRT application and it looks like that there's no StorageManager class, anyone has suggestions about how to persist application/ViewModels state in this case.
TIA
This is not related to Caliburn.Micro but rather a general issue. You can either use Serialization but then you will have to pay attention to versioning and changes in your view model or you could save the fields you are interested in to a file using the normal IO methods or even store your view models in the database if you wish (although i think this might be a bit extreme).
Edit: Caliburn.Micro isn't a business application framework and there have been no library that tried to integrate business functionality with CM as far as i know, so this leaves you with serialization as your best option but as i said ser/des comes with some nightmares you have to manage such as version changes, class changes, etc.
There's another project called Catel which is a business application framework that contains an MVVM framework, anyway Catel uses a nice object called DataObjectBase ( actually now it is called ModelBase) which solves all problems of serialization and there is an article for that on code project if you want to read it and see how they have done it.
If you wish you can use the Catel.Core module which is a library with a lot of features for data handling (it contains the ModelBase class) or you can take a look at the source code and see how they have solved the issue with ser/des and implement that with Caliburn.Micro in your project.
In the official documentation is just shown code with explanations not about a project apart. My question is: Do I need to create a stand alone project which will contain interface and plugin class? And which project template should I use? C++ library?
Knowing Qt's plugin architecture is probably not going to help you much when extending a 3rd party application. The application will undoubtedly have wrapped that mechanism for it's own usage patterns - assuming that the application is even extendible.
So to answer your question directly: The application you are developing for should have it's own API and documentation for extending it, reading that will give you the answers you need.
Is it possible to include a .net 3.5 framework DLL in classic asp?
You will need to expose this .NET assembly as a COM object. This could be done using the regasm.exe utility. For this the types that you need to use or the entire assembly must be decorated with the ComVisible attribute.
Then consume the COM object from classic ASP as you would with any normal COM object.
Yes, it's called creating a COM-Callable Wrapper.
Here is the MSDN Documentation
The link that pops up for the Code Project article in Google is, surprisingly, not the better one. You'll want to check out this one: Exposing .NET Components to COM It's the best. Complete step-by-step tutorial.
It's worth noting that in a former life I had to develop and support a .NET application which was exposed to some COM-based integrations - and simply slapping ComVisible on my classes was putting me in a world of hurt. Pay attention to the author's explanation of the Interface Types in that article... that article is a gem.
Excerpt:
Previously I was using AutoDual,
however Heath Stewart[^] pointed out
this was not the best method to use as
it can create version-related problems
in the long run. After reading a
little more I changed the code to use
ClassInterfaceType.None which forces
our class to gain access only through
our interface. This keeps everything
viable during changes to the class in
the future.