Can I use code-effects business rules for Windows Applications or Console applications?
I want to define the rules using the rule editor but want to execute those rules as a service.
Yes, you can if you are OK referencing System.Web assembly in your project.
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.
VS gives me errors when I try to do it. Yet, it displays such projects as available to reference. Is it possible to add winRT project reference to the classic class library project somehow?
If not, how to bridge both worlds, so common logic can be stored in one place?
The short answer is yes. The long answer is that it's not supported and comes with some caveats that you need to understand.
See my answer here:
Using Custom Windows Runtime Components in Non-Metro Applications
VS2012 adds a "Portable Class Library" project type that allows you to select multiple targets, including the ability to target WinRT and full .Net 4.5 from one assembly.
See http://msdn.microsoft.com/en-us/library/gg597391.aspx.
I'm porting a Windows Phone 7 app to work for Windows 8 (and take advantage of the new form factors available).
There appears to be a handy namespace map for a lot of the namespaces, and there are some that are explicitly called out as not avaialbe, but there appears to be no mention of LINQ-to-SQL - is this an omission in the documentation, or is it not available in metro style applications?
LINQ-to-SQL and LINQ-to-Entities are not available in Metro-style apps. Metro-style apps are meant to be lightweight apps which can retrieve data from web services (generally running in the cloud).
Thus, ADO.NET and the entire System.Data namespace is not supported.
Mention was made in the Windows Phone Summit on Wednesday that SQLLite would be available on WP8 and Win8, but no details as to the programming API's were shared yet. Currently the Metro subset of .Net for WinRT applications does not include a database API set. There are some independant efforts to port some of the no-sql based implementations, including RhynoDB and Sterling, so you may want to keep your ears open to further announcements.
I have created a simple XNA Windows Class Library with XNA 4.0 called "NivekGameEngine". I have created a simple game for the Windows platform, and I can access all contents of my dll just fine.
The problem comes when I try to make a copy of this project for the Xbox 360. I get this as the error:
The primary reference "NivekGameEngine01" could not be resolved because it has an
indirect dependency on the framework assembly "mscorlib, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089" which could not be resolved in the
currently targeted framework. ".NETFramework,Version=v4.0,Profile=Client". To resolve
this problem, either remove the reference "NivekGameEngine01" or retarget your
application to a framework version which contains "mscorlib, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089".
I look back at my project that created my dll file, and the target is set to "4.0 Client"
Is there a way of fixing this? I will upload code if necessary.
I believe the issue is that you either need to target the .Net Compact Framework or Silverlight (not 100% sure which) for XBox 360 development. The full .Net framework, including the Client Profile version, doesn't appear to be supported.
So you will either need to rebuild your DLL for one of these environments or, if it is used in other applications, create a second project for the appropriate platform and add references to the files in the original project. You may find that you will need to add conditional compile statements to the source code if you are using features or method overloads that are not supported on the platform.
This is all very doable: we have one set of source code that services the full framework, Compact Framework, Silverlight, and Mono.