I have a WinRT Metro style application that uses MvvmCross. The application is made up of several DLLs and many of them are taking some dependencies on MvvmCross. For example some of the DLLs use MvvmCross as an IoC container.
At this point, I would like to add to the application a WinRT background agent. The background agent will reference some of the existing DLLs that have MvvmCross dependencies. Because of this, I need to set-up MvvmCross in the context of the background agent. Obviously, if this is even possible, the way it is done in a background agent must be different from the way it is done in a WinRT application. In the context of the WinRT application you need to create a "Setup" class inherited from MvxStoreSetup and define a constructor that takes the root frame (Window.Current.Content) as a parameter. Obviously, in the context of the background agent there is no "root frame". Also, inheriting a class from MvxStoreSetup in the background agent code will lead to a compiler error:
Windows Runtime class ...backgroundagent.MvvmCross.Setup' has an invalid base type, 'Cirrious.MvvmCross.WindowsStore.Platform.MvxStoreSetup'. Classes must derive either from System.Object or from a composable Windows Runtime class. Implementation inheritance is not allowed.
Does anyone has any knowledge on how to setup MvvmCross in the context of a WinRT background agent?
Thanks
It's unlikely you'll want to setup the full MvvmCross - as that would include ViewModels and Views
For example some of the DLLs use MvvmCross as an IoC container.
It's easy to just setup the IoC container on its own - just call MvxSimpleIoCContainer.Initialize() in your service's start code.
To load plugins you'll also need to create a plugin manager and to register that with iOC using code like in https://github.com/MvvmCross/MvvmCross/blob/v3.1/Cirrious/Cirrious.MvvmCross/Platform/MvxSetup.cs#L214
Putting this together, you can create your own mini-Setup if you want to - based on code from the default Store Setup class - https://github.com/MvvmCross/MvvmCross/blob/v3.1/Cirrious/Cirrious.MvvmCross.WindowsStore/Platform/MvxStoreSetup.cs - although this would probably be overkill if all you really want is IoC
Related
Is there a quick way to modify environment variables, or configurations (that is accessible) for a module in IoT Edge?
Once a deployment is created, the environment variables become read only.
What would be the best practice of maintaining a modifiable set of configurations, so I can rather easily change them on the fly, and have the module be able to access them?
On Azure Cloud Services, for example, there are web configurations that are editable and would restart the service so they would kick in (since they are accessible to the service). I am looking for the same kind of behavior.
You can modify the module's device twin in the portal and deploy it. The module should be informed of the update. Alternatively you could send your module a direct message.
Screen shots on how to update the IOT Edge Module's Environment Variables.
Note, I am using the VisionAI Kit camera in this example.
Screen shots on how to update the IOT Edge Module's Environment Variables.
Note, I am using the VisionAI Kit camera in this example.
Your scenario is Cloud To Device (C2D)communication. Refer here for details.
Out of all, the best match is Module Twin Desired Property update.
You can easily create handlers for desired property updates in your edge module implementation and run custom logic based on the changes in desired properties.
For C#, the handler code would go like -
await ioTHubModuleClient.SetDesiredPropertyUpdateCallbackAsync(OnDesiredPropertiesUpdate, null);
This would be a great read on it.
P.S : Environment Variables are designed to be read-only after deployment. It should only have configurations that are deployment specific and do not change post deployment.
I'm working on a UWP app (C++/WinRT) that must communicate extensively with a background process. Unfortunately, the background process must remain a full trust "Win32" process. Both are packaged in an MSIX.
For performance and programmability reasons, my first choice would be to turn the background process into an out-of-process WinRT component. App Services is a possibility but not ideal.
I've found numerous code samples for creating an OOP WinRT component via WRL. However, activation is performed via CoreApplication::RunWithActivationFactories(), which (as far as I know) requires an AppContainer.
I know I can consume a WinRT component in a Win32 process. Can I create one? If so, what would activation look like in C++/WinRT?
Yes, from the Windows 10 Version 1903, May 2019 Update, the windows have added support for non-packaged desktop apps to make use of user-defined (3rd party) Windows Runtime (WinRT) Components, which means that we can consume a Winrt component from the Win32 process directly. To successfully reference a C++ Windows Runtime component from a Win32 app, you need to use C++/WinRT to generate projection header files of your component. You can then include these header files in your app code to call your component.
For the detailed information, please refer to this article:
https://blogs.windows.com/windowsdeveloper/2019/04/30/enhancing-non-packaged-desktop-apps-using-windows-runtime-components/.
For the detailed sample, please refer to here:
https://github.com/microsoft/RegFree_WinRT/tree/master/Cpp.
Thanks.
Visual Studio provides a "Background Application (IoT)" template which i want to use to create a headless webservice. To persist some data i want to use Entity Framework with SQLite as DB-Engine .
After upgrading UWP to 5.2.2 and installing Sqlite and EFCore.Tools and adding a DbContext i wanted to migrate the first version. It fails:
PM> Add-Migration MyFirstMigration
Project 'BackgroundApplication4' is a Windows Runtime component. The Entity Framework Core Package Manager Console Tools don't support this type of project.
I thinks it's not a problem with EF itself, because it worked for me with a simple "Blank App". Now there are some questions coming up: Is a "Background Application" really a WinRT-Component and has a different (unsupported) handling by EF?
I thought UWP is an extension of WinRT so basically each UWP-App must be a WinRT-Component?
EF in a Windows Runtime component is a no-go; but that is not so bad since WinRT component can depend on class libraries. So move all your EF classes to a own class libary and consume that library from your background task in your Windows Runtime component.
By doing this you can also use the same class library also in the foreground app when needed.
P.s. Check the github page of EFCore and UWP. There are lot of issues especially in combination with .net native. so using EF.core in UWP will cause you lot of headache; but it is possible.
i would like to know if it's possible to define a new user control on the basis of the pre-defined ones in WP8. For example, if i wished to define a custom Application Bar (like the one in the Windows Phone Store) starting from the standard one, or a custom Context Menu, would it be possible?
Thanks
The simple answer is "yes." For instance, a vast majority of the controls in the Windows Phone Toolkit are derived from their base-level analogs, such as the most obvious example of PhoneTextBox.
Regarding ApplicationBar specifically, you will note the class is sealed and cannot be inherited, but you can create predefined templates in XAML for application bar configurations you wish to reuse. As a custom control, that specific construct does not make sense as it is a baked-in OS element. Instead, depending on your use case, it may be better to completely disable the ApplicationBar and create an entirely new control that implements the custom functionality you desire.
The controls are skinned using a convention in Windows Phone development by generating a Generic.xaml file in the Themes folder that is compiled as a library resource. One such example can be found at the link inside the Windows Phone Toolkit's WP8 library.
Just started with NServiceBus and I am trying to understand how the bus fits into my VS solution.
Let's assume an existing application, that has an ASP.Net front end and a BLL. I am using Windsor for DI and my BLL has no knowledge of the container. I wire the container up in a separate project I call "MyNamespace.IOC", and only this project and my web project have knowledge of Windsor.
I need access to the bus in my BLL (since that is where I will be sending/publishing/handling messages). I need to configure NSB using Windsor, and (I think) pass an instance of my container to the Configure.With().CastleWindorBuilder() method at app startup.
It seems odd to have all three projects have reference to the NSB DLLs. How does one normally wire this all together?
If you do not want to reference NSB in your BLL / domain layer you could have a look at 'domain events'. The domain event handlers can sit in their own implementation layer leaving your domain ignorant of the handling of the events and, therefore, requiring no knowledge of the service bus. From there you could publish your esb messages. It may not seem like much of a difference but the domain event-handling layer is more isolated from the domain.
Just as a side-note: since you are starting out with a service bus you could also have a look at my FOSS project over at http://shuttle.codeplex.com/ --- any feedback would be appreciated :)
You can abstract bus behind some interface and provide the implementation only in IoC and Web projects.