I started work on porting an application I've written for deployment in the Windows 8 app store. This requires that the application be written against the subset of the .NET framework. My application follows an architecture where the core functionality is in it's own dll, and things like file system access are done through IoC. Basically, this means that the only dependency for the core dll is System. Because of this, I thought that porting would be a breeze - setup my IoC values and wire up a GUI then I'll be good to go. Only, I can't even reference my core dll from the windows store app (a.k.a. metro app).
Have I missed something? Do actually have to rewrite my core dll just for inclusion in the windows 8 app store? We're told that if you use a good architecture, then porting will be a breeze, and that's what I've done. Has that just been a big lie?
Windows store apps(formerly called metro style app) are limited to using the .NET Core Profile. I put some details about the Core Profile in my answer to this question. See Converting your existing .NET Framework code in this article more details. It's not your architecture, it's the subset of the .NET Framework that is available to a Windows store app. You may have to supplement some of the types you use in .NET with WinRT types instead.
I don't have an extensive knowledge and will try to stict to facts as I understand them. The Metro framework adds functionality, and limits functionality. There are heavy security restrictions and vast segments of the full .Net framework that are not available (for instance, you cannot use System.Data, some of the System.IO and file access methods have drastically changed). A Metro app is isolated, you're not going to be able to recurse all the files on the hard drive like you could in a standard application (my opinion that is, on top of security by isolation it's an encouragement to push you into the cloud for storage needs).
Unless things have changed, PInvoke is limited to "approved" Win32 API methods.
See this link for some alternatives to common Win32 API needs: http://msdn.microsoft.com/en-us/library/windows/apps/hh464945.aspx
See this link for approved Win32/COM API's: http://msdn.microsoft.com/en-us/library/windows/apps/br205762.aspx
It's hard to say whether a "good" architecture will be a breeze to port without knowing what's in the code in that architecture. In my utility framework I've had things that ported very easily (or at least were straightforward) and things that were a complete wash that required a lot of rewriting (The loss of System.Data for instance is a sore spot for me). There are things that can be designed well but when you take out the underlaying code in the framework or API it was written with it will require rewriting.
I had the same problem: a project for Metro app don't load dll create with framework .4. I changed the framework from 4 to 3.5 for the dll and now the Metro project see them.
Related
I'm lead dev on a new project at work to build a combination web and mobile app for internal project management. The descriptor "internal project management" is generic and may mean different things to different people, so please don't focus too much on that. Most of our stuff is M$ and C# is the future (compared to my company's history with VB, VBA, VBS), so I'm thinking C# and Xamarin. Know any good literature on making the most of shared codebase for mobile/web with Xamarin/C#.NET?
To my knowledge, Xamarin does not support web app development, only "iOS, Android, and Windows Phone 8.1, Windows 8.1, and the Universal Windows Platform (UWP) for Windows 10". Unless we have a reliable timeline for the entire company upgrading to Windows 10 (we don't) we shouldn’t build in that direction. We can maintain two closely related codebases of C#.NET and Xamarin. The trick is how closely?
Thoughts? Thanks!
I would highly recommend reading the new bits to .NET: https://learn.microsoft.com/en-us/dotnet/articles/standard/library or https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
Xamarin now supports .NET Standard:
https://blog.xamarin.com/net-standard-library-support-for-xamarin/
Because of this, you can leverage the use of .NET Standard as a Shared layer across your applications. You would then treat each stack (Web, Desktop, Mobile, etc) as a platform specific stack that you would implement native features/UI/etc into. However you can completely leverage all of your shared code via the standard library.
This is a common question answered in the FAQ here:
https://www.xamarin.com/faq#q2
Or expanded upon via our documentation:
https://developer.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/sharing_code_options/ (Note: This will be expanded in the future to include .NET Standard)
We have a big application in .Net 4.5, with WPF and a lot of references like NHibernate, Fluent NHibernate, Enterprise Library, Unity and others.
I was asked to investigate whether we can run this (after some work done) on Windows 10 IoT. As far as I know I need to port the app to Windows Universal App, and as I understood this is impossible as NHibernate won't work for Universal App.
WPF is not a problem though as we agreed we can throw frontend away if we have to.
So I wanted to ensure my understanding is correct and the only way to run our app in Windows 10 IoT is to rewrite it without NHibernate and all other 3rd party libraries that currently do not support Windows Universal App. Is this true? If no what should we do to make it work and does it require a big effort?
If you have a core with all the functionality in it and its separated from the front end it should be possible to use that core and then build a new front for it with UWP.
The UWP is more limited regarding access to libraries and frameworks due to it being adaptable by several platforms so might need to rewrite some platform specifik code.
So the answer depends on how coupled and platform specific the code is as it is now.
I've studied Windows Services and .Net framework.
From my research, a windows service is a type of application that is primarily used to run in background and can be done automatically or periodically. And
.Net is a software framework developed by Microsoft that runs primarily on Microsoft Windows.
What I would like to know where in the stack of the .Net framework are basically the windows services, supposing windows services use .Net framework.
Any further exaplanation on the relation between these two will be a great help.
Thanks.
They are two completely separate notions. They're related in the way that, for example, a hotel janitorial staff might be related to a guest of the hotel. Just because they reside in the same "building" at some point, doesn't mean there is any "useful" (i.e. substantive for the purposes of comparison given the context) relationship between them, though their paths may cross for whatever reason. The same goes for the notion of windows services and the .NET framework.
Windows services can be written in many languages, including .NET languages. .NET itself has a built-in project template for creating a Windows service.
based on your post:
"windows service is a type of application that is primarily used to
run in background and can be done automatically or periodically"
that is correct, as others mentioned above, you can use any framework to build those services.
Regarding the second portion of your question:
" .Net is a software framework developed by Microsoft that runs
primarily on Microsoft Windows"
Is exactly that, a framework, you can use this framework to create the above mentioned services.
A windows service is just an application that runs without user interaction, .NET is a set of tools you can use to build such applications.
You already have the answer you were looking for.
A service does not have to be written in .NET, anything will do. Two basic things need to happen. First of all, the Service Manager built into Windows needs to know that the service exists. That requires writing a handful of registry keys. Bare essentials are the service name, where the EXE is located and how it should be started. The ServiceInstaller class you write takes care of that, you run InstallUtil.exe to let that installer do its job. Have a look-see with Regedit.exe, navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services key.
And then the program needs to use a winapi function to talk to the service manager. So that the manager can deliver notifications that tell service to start, stop, pause, etc. That's wrapped by the ServiceBase class, you get friendly methods you can override. Like OnStart(), etc.
That's all there is to it. The service manager takes care of the heavy lifting.
A windows service is a type of application that has been around a long time before .NET.
You can write a Windows Service in many programming languages. You can write a Windows Service in .NET and a language making use of it (C#, VB.NET, etc) but that is not required. You can also use other languages that do not use the .NET framework to write a Windows Service.
Windows-7 introduced a concept of virtual folder, called 'Libraries'.
I am working on implementing a Library with my custom action. The constraint is that, I have to stick to .NET version 2 for this :(
While looking around, I didn't find any native (c/C++) API for doing this. I am planning to use Interop (p-Invoke) to make a library once I get native APIs.
Could any one point to a link or documentation which might help. If somehow I can do this directly from c# (with .NET v2), that would be great.
Thank you,
John
The MSDN topics that seem most pertinent are:
Inside Windows 7:Introducing Libraries
Windows Libraries
Windows 7 Libraries: Developer Resources
The library features are exposed through COM so there's no need for P/invoke.
However, since libraries only exist in Windows 7, and since Windows 7 has .net 3.5 as part of the OS, I would recommend that you put this part of your application in a .net 3.5 assembly. In fact the API CodePack assembly already does this for you.
Of course, since the CodePack is also delivered as source you could extract the necessary parts from there and do what is needed in order to build it against .net 2.0.
The concept of "virtual folder" exists already before Windows 7 and has AFAIK just been "refined"... you write you want to do this with your own custom handler...
IF you want to implement such a "virtual folder" and integrate it into Windows so that other applications can use it as a "virtual folder" then:
To implement and install a "shell extension" (which basically are a bunch of COM interfaces):
Remark: If the system you are running on doesn't have .NET 4 then Microsoft recommended NOT to use .NET for this because of the inherent restriction with the older versions that one process can't run multiple framework versions at the same time. Depending on the OS etc. case it could be recommended to implement this with C/C++.
Even with .NET 4 as pointed out in the comments the code injection problem remains - i.e. if any .NET app prior .NET 4 and/or with a different .NET versions than your shell extension accesses the file open dialog for example it can/will fail.
To circumvent that you need to implement a native proxy DLL which gets loaded into the respective processes (like Windows Explorer) and communicates with your .NET implementation via IPC.
In this specific case you need to build a shell extension which implements IShellLibrary.
That aside the implementation of shell extension is a really tough job... some links with information / samples / source code / libraries etc.:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb774328%28v=VS.85%29.aspx
http://blogs.msdn.com/b/codefx/archive/2010/09/14/writing-windows-shell-extension-with-net-framework-4-c-vb-net-part-1.aspx
http://www.ssware.com/ezshell/ezshell.htm
http://www.codeproject.com/KB/shell/ratingcolumn.aspx?q=shell+extensions+c%23
http://www.codeproject.com/KB/shell/shellextguideindex.aspx
http://www.nirsoft.net/utils/shexview.html
http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/1428326d-7950-42b4-ad94-8e962124043e/
To interact with a Windows 7 library see http://support.microsoft.com/kb/976027 and http://www.codeproject.com/KB/miscctrl/Windows7APICodePack.aspx and http://archive.msdn.microsoft.com/WindowsAPICodePack and http://www.codeproject.com/KB/cs/DDW7LibrariesLite.aspx . Some require .NET 3.5 but since 3.5 is just 2.0 plus some additional assemblies it might be an option...
Briefly searching in google, found this: How to programmatically manipulate Windows 7 shell libraries
if C# examples are not useful, it should be possible to export api methods used in c++ example.
I'm developing an application for a Windows based tablet PC. This application is pretty much a port of an application I already developed on a Windows Mobile device using .NET CF. I want to write the application from scratch, taking advantage of all of the knowledge I've gained in software development.
I'd also like to write this new application in such a way that if I so desire, I can modify my existing Windows Mobile app to use the new libraries. Ideally, I'll have a shared set of business logic and data access libraries, with the only real difference being the UI layer - WPF for the tablet version, and just a standard CF interface for the Windows Mobile app.
Taking this into account, I'll need to make sure that all of the projects I create are compatible with the .NET Compact Framework. Is there an easy way to ensure this? One thought I had was to use a Smart Device Project for each class library that I create.
As well as this, is it easy for me to reference these libraries written for a .NET CF application from a standard windows application?
Is developing an application for a tablet PC the same as developing any normal windows forms application? Is there a different version of the .NET Framework to take into account, or are tablets pretty much standard windows pcs?
There isn't a special version of .NET Framework for Tablet PC. The question of sharing code between Windows Mobile and Windows has been asked before and the accepted answer is excellent.
The tablets I've seen are running standard Windows with the "full" .NET, but I expect you can get some light-weight devices, too. One interesting possibility might be "client profile" (a subset of the regular "full" .NET dlls) - but I haven't seen much use of that myself.
CF and regular .NET share a lot of things, but ultimately there are differences; neither is a strict subset of the other. I've found that in general the only way to write code for 2 frameworks is to keep both active... for protobuf-net (which has this problem) I keep a project file for each framework so that I can quickly test that the build works everywhere (i.e. there are no missing methods etc).
You may find you need to use #if blocks to run slightly different code on the two frameworks, especially if you want to use "full" .NET features for performance reasons (that don't exist in the CF version). One way of making this easier it to hack the proj files to use recursive file inclusion:
<Compile Include="**\*.cs" />
Now you don't have to keep adding new files to both projects - it'll get picked up automatically (caveat: in the IDE you may need to unload/reload the project).