I have a goal to build an application with UI that would run on both Windows Mobile and "normal" desktop Windows. The priority is for it to "look good" under Windows Mobile, and for desktop Windows it is OK if it distorted. Before I invest days trying, I would like to hear if that is possible to begin with. There are several parts to this question:
Is .NET Compact Framework a subset of "normal" (please, edit) .NET Framework? If not, does MSDN have any information anywhere on classes that are in .NET Compact Framework, but not in "normal" (again, please, edit) framework?
Is behavior of shared classes same in both frameworks?
Is it possible to have a single Visual Studio 2005 solution / project for both platforms? If yes, how do to set it up?
Any other comments and advice? Any relevant links?
The CF contains a subset of the full framework (FFx), but it is not a pure subset. There are actually several things available in the CF that aren't in the FFx, which makes it a bit more difficult. CF apps also, except in the most rudimentary cases, use P/Invoke. Those calls are never the same from the desktop to the device, so they are not directly portable (though with a little abstraction you can have a platform-agnostic interface).
For the most part, behavior is the same. I've seen some cases where it's not, and I recall some event ordering not always being identical though, so trust but verify.
It's possible through very careful massaging of the configurations, but I certainly don't recommend it. It's difficult to maintain and very fragile. Instead have two project files, one for CF and one for FFx. You're likely to have code file differences anyway. Add the code files as links to each project so they both use the same physical source file. I'd recommend using some form of CI to help ensure they both build at all times.
Take a look at Dan Moth's MSDN article and blog entries on sharing code assets.
P.S. I found the poster online - it'll show you all the classes that are CF. I ordered it fro Microsoft because Kinkos wanted $65 to print it out in color for me! Microsoft sent me a couple of copies free - all I had to do was ask:
http://www.microsoft.com/downloads/details.aspx?familyid=7B645F3A-6D22-4548-A0D8-C2A27E1917F8&displaylang=en
I have it hanging in my cubicle and it's a godsend when trying to remember which namespaces classes can be found in.
Nice multi-part question:
Differences between the Full Framework and the Compact Framework
The article above has links to relevant documentation about how class behavior differs (it definitely DOES differ in some situations)
Very simple! Create a single solution with a set of base functionality in a Class Library, then create two client projects (one for your desktop app and one for the windows mobile app). Finally, add references to the class library to both client projects.
Depending on the breadth of the project you are working on, you may want to check out the Model View Controller pattern. It may be a bit much for your project, but if you want to share UI behavior between projects, it can be a life saver.
Hope that helps!
CF, in general contains a subset of the classes from the regular framework - but you can't directly execute code from one on t'other. Additionally, rather than just being a subset, there are probably a few things in compact that aren't in the regular version, such as the GUI things specific for mobile devices (soft keys, etc) - assuming you are writing a winform exe, and not a web page (which might be the simplest way to get compatibility).
With some effort, it it possible to share logic code, in particular utility dlls - but they need different csproj files (since they have completely different compile-time "targets"). To reduce maintenance, you can often cheat by hacking the csproj to use wildcards, like from here:
<ItemGroup>
<Compile Include="..\protobuf-net\**\*.cs" />
</ItemGroup>
For UI, things get a lot tricker. In general the expectation would be to have shared business logic and separate UI for different target devices.
1). There is a Compact Framework so yes; And it is a subset of the full .NET framework. I've got a poster on my wall at the office that denotes a whole bunch of classes that work in CF... I don't recall off the top of my head if there are any that are purely CF, but I suppose there must be some. There are a couple of good books on the subject - one by Paul Yao that I have and another by Andy Wigley - both are available on Amazon.
2). As far as I'm aware, the classes that are CF and full framework work the same but need to be compiled for different targets.
3). I would hazard a guess that providing you only use classes that are common to both, that you could use the same solution, I don't know the extent you would have to go to make it compile for the compact device and the full version though, nor can I say with complete certainty that it can be done. I'd hazard a guess that the process isn't simple.
4). Go to your local book store and have a flick through those two books I mentioned. Like I said, I have the one by Paul Yao and it seems to cover most of what I could imagine needing on a compact device.
Related
I have an application that I have designed and this app has a pretty decent core dll that contains an API that my main view's exe uses. I would like to allow other developers to access this core dll as well but I don't want them to have as much access as me since it would be a security risk. What is the standard way of exposing my core dll? Are there any particular design patterns I should be looking at?
I'm using C#
Edit: my question was a little vague so here is some clarification
My program is deployed as a windows exe which references the core.dll. I want other people to create extensions which dynamically get loaded into my program at start up by loading dlls in the /extensions directory. The 3rd party dlls will inherit/implement certain classes/interfaces in my core.dll. I only want to give 3rd parties limited access to my core but I want to give my exe additional access to the core.
I should mention that this is the first time I have written a program that imports DLLs. Perhaps this whole method of allowing users to add extensions is wrong.
How do I modify/expose my API for
other developers?
To deliberately allow other developers to work with an API you've built touches on many things, which can be broken into two areas:
Resources (documentation, samples, etc) that makes it easier for them to understand (yes - basically an SDK).
Architecting, constructing and deploying your solution so that it's easy to actually work with.
Examples include:
By packing it in a way that suits re-use.
By using naming conventions and member names that others can easily follow.
Documentation, samples.
Providing the source code (as open source) if you're happy for them to modify it.
I would like to allow other developers
to access this core dll as well but I
don't want them to have as much access
as me since it would be a security
risk.
Ok, so this gets us right into the second area - the actual solution.
The problem you have is not a trivial one - but it's also quite do-able; I'd suggest:
Looking into existing material on plugins (https://stackoverflow.com/questions/tagged/plugins+.net)
Personally, I've found using attributes and Dependency Inversion to be a great approach.
There's also stuff like the Managed Extensibility Framework which you should consider.
The big issue you face is that you're into serious architecture territory - the decisions you make now will have a profound impact on all aspects of the solution over time. So you might not be able to make an informed decision quickly. Still - you have to start somewhere :)
The "design patterns" in terms of an API are more related to things like REST.
I don't want them to have as much
access as me since it would be a
security risk
Then i would (for the sake of maintenance), layer on top of the core DLL extra logic to prevent this.
The thing is, the "clients" call the API, not the Core DLL.
"How" the API accesses the Core DLL is under your full control. Just only expose operation contracts that you wish.
Since you're using C#, I would look at Microsoft's Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries and use FxCop to in-force many of them (latest version here). This won't be all you'll likely need, but it would help put you in the right direction.
Also, take a look at the freely available distillation of Framework Design Guidelines by the same author.
I am quite aware of both java and C# .Net .when i try to create a new windows application which are the factors that decide which technology should be opted?
I know of one thing ,for great and faster UI development Visual studio helps a lot.
There are several factors I would consider...
What are your programmers used to working with already? What third party libraries are you likely to need, what's available on both platforms?
Does platform independence matter to you?
Would LinQ be advantageous?
If you're starting from scratch, costs for the platforms?
Both platforms have strong communities around them...
Hope this helps...
Dotnet is pretty much native in Windows which obviously makes it more suited to writing Windows programs. Using Java in a Windows-only environment makes it much harder for you since it effectively just adds another unnecessary API layer.
You will soon realise that all integration points between your Java code and Windows are a bit problematic. For instance, creating installation programs, access file system, reading/writing the registry, starting/stopping services, task bar icons, using Windows GUI components (media player, IE...), help file system...
It all boils down to this imo: The Dotnet framework is much richer in terms of functionality than the Java dito, mainly becuase Java is cross-platform and thus needs a "one-size-fit-all" approach to its API. My experience is that you will only get frustrated trying to "emulate" a Windows native program in Java.
Choose the one with which you are most familiar. The two platforms are different enough that skills from one does not transfer easily to the other.
In any case, try making a trivial application in both your scenarios and see how it works for you. The initial impression is important as it is probably indicative of how well the rest of the work will be.
It also depends on what kind of windows application you want to build. If it's just a question of building a simple standalone application then, considering you know both languages equally well, I wouldn't hesitate and would go for a 100% microsoft solution, especially if you have to do specific things like accessing ActiveDirectory, the windows registry, etc.
Not that you can't do it in Java : you can always use AD through LDAP in Java for example, but the APIs are just "a bit" more complicated than the .Net ones (try to decode objectSIDs in Java without a few tricks).
Now if you have to build an enterprise app. I just feel that popular frameworks like Spring and Hibernate are always coming out after their Java counterparts (disclaimer : this is a personal opinion; I didn't do any research on this, thoroughly comparing frameworks in both languages, but that's just the feeling I have). I don't know how good the .Net implementations are though, so I don't have a point of view on that. I just remember writing .Net 2.0 apps and not liking ADO.Net at all.
My view is that the frameworks I like do exist in both languages, but they are first developed for Java, then ported to .Net.
Now I'm not the kind of developer trying to defend his favourite language over the others. If I don't have external constraints to develop, then I choose whatever language gets my app up and running faster and in the most efficient way.
...But with java you will have crossplatform application on scratch.
Also coding UI in java is not difficult - if you read some guides before and use some frameworks as swing application framework or SWT framework.
If its Exclusively for Windows then .Net is best bet.
Yeah for a pure cross platform application Java can't be beat, but if you can manage it Silverlight is a subset of WPF and a pretty compelling cross-platform proposition on its own.
Productivity-wise I think WPF has an edge as it has a nice XAML markup language that can be easily created with the built-in designer in VS.NET or integrates nicely with MS' suite of expression products.
We're developing with Compact Framework for a device under Visual Studio 2005. However we want to make an emulated version of the software as well, running at the PC (preferably selectable via a Build Configuration).
It seems however that the .vsproj file is specific for devices; there is no way to use the full .NET framework for example by just changing the target.
Is there any way around this? I suppose we can run the compact framework on the PC, but still the project can't target for example an ARM processor or else I assume the JIT compiler will generate unusable code for the PC?
You can run a Compact Framework application in regular Windows (maybe). There are two major potential problems with this, however.
First, because certain form and control properties present in the full framework are missing in the compact framework, your application will behave a bit oddly in Windows. For example, in the full framework forms have a StartPosition property which determines where the forms appear on the screen when they're first created. This property does not exist in the compact framework (for obvious reasons), so when you run your CF application in regular Windows, the forms pick up the default StartPosition value of WindowsDefaultLocation, which means that setting the form's Left and Top properties has no effect on where they appear, so the forms pop up wherever.
Second, any Windows API PInvoke calls in CF must reference "coredll", whereas the same calls in the full framework reference "user32", "winmm" etc. One way around this problem is to do something like this:
[DllImport("winmm.dll", EntryPoint="waveOutReset")]
private static extern int waveOutResetFULL(IntPtr hWaveIn);
[DllImport("coredll.dll", EntryPoint="waveOutReset")]
private static extern int waveOutResetCF(IntPtr hWaveIn);
public static int waveOutReset(IntPtr hWaveIn)
{
if (Environment.OSVersion.Platform == PlatformID.WinCE)
{
return waveOutResetCF(hWaveIn);
}
else
{
return waveOutResetFULL(hWaveIn);
}
}
There are other ways to do this, also.
Regarding the first set of problems, one solution is to set the properties that are missing in the compact framework via Reflection when the application is running in regular Windows. I think a better alternative is to encapsulate all the elements of your UI as UserControls, each one hosted on a single "master" UserControl that creates and disposes the other UserControl elements as needed. You can then host your single "master" UserControl on a single instance of a form.
By the way, I wrote an application that does exactly this (run in Windows and on Windows Mobile devices) for a major shipbuilder, and it is still in use. In fact, the ability of this application to run in both environments literally saved its life when the use of mobile devices in the shipyard was temporarily suspended for security reasons.
Jared is correct, you cannot get Studio to do this (well not without a whole lot of pulling your hair out and very brittle end results). In addition, though, there are som other things to note.
First, MSIL is processor independent so it's not going to "generate unusable code" from that perspective. ARM IL is identical to x86 IL (or MIPS or SH3 for that matter). In fact CF assemblies can be directly used in the full framework becasue they are retargetable (the reverse is not true since the CF doesn't implement all of the opcodes the desktop does).
That said, it's pretty uncommon to have a CF application that doesn't call a device specific API, whether it's a P/Invoke to coredll.dll or a device-specific assembly like Microsoft.WindowsMobile.dll. In those cases the assembly either will except at runtime (cannot find a native DLL) or at load (cannot find a referenced assembly).
You can (sometimes only with great effort) work around these issues. It's up to you to determine if it's even worth doing. My experience is that, generally speaking, it is not. It's way less effort to just use the emulator or a Virtual PC running CE.
I think the only way to do this is to have 2 project files for the same project. One which is the normal CF one and one that works just like a normal .Net application. Having the project file target both the CF and full framework is not a supported operation.
I have a related issue in some open-source code that I maintain; I have separate project files, but to reduce maintenance, I use a hand-crafted project file that automatically includes all *.cs files in the project tree:
<ItemGroup>
<Compile Include="..\protobuf-net\**\*.cs" />
</ItemGroup>
This way, I don't have to keep remembering to add files to the other build scripts - although I do need to be religious about deleting obsolete files (not just removing them from the project).
We do this where I work and it's (mostly) fine. If you're only using it for emulation you can also handle the few rough edges that the GDI+ spits out. You just have to identify the incompatible points and push them out into some sort of platform interface for those issues that seriously break things.
As MusiGenesis astutely states one of the main areas will be your P/Invokes. I also have a very incomplete list of Compact Framework / Full Framework bugs being gathered here:
A workaround is NOT to use VS. One great example is the software Basic4PPC (see here).
It's a programming-language in the style of VB.Net (all applications written with it requires the Compact Framework installed on the device). However, the point is that you use only one IDE, same source-code but you can compile your applications to run either on the desktop or the device. There are many user-libraries available and for certain tasks, you might be required to use a specific library for the desktop or the device.
The program has been written in C#. It's well worth a look.
I've tackled a similar problem from a different direction: I have a utility library that works in both full and compact, so I used multiple projects, but only a single set of source files.
The full csproj has the source files, and the compact csproj has links to those files. Whenever a class calls a method that isn't in the compact, I make that a partial class and the methods in question are implmented in *.pc.cs and *.ppc.cs files.
Combine this with the concept with Marc Gravell posted (to automatically include files from the full project), and it should be pretty easy to maintain.
Having just gone through a small experimenting session to try to see how much work it would take to bring our .NET class library, or at least portions of it, into Silverlight so that we can reuse business logic between the two worlds, I'm wondering if others have experience with this sort of thing.
The things I noticed, off the top of my head:
Lots of attributes missing (Browsable(false) for instance)
Lots of interfaces missing, or present, but empty (ICloneable is hidden, ITypedList missing)
Reflection differences (everything reachable needs to be public)
Some base class differences (no Component?)
So I'm wondering, is it really feasible for me to even look at this as a possibility?
I got the initial code running, but I had to just comment out a whole lot of the base functionality, mostly around handling lists since they are based on ITypedList and some base classes. Apparently I need to change to ObservableCollection in Silverlight, so a whole of of base-code needs to be changed in order to cope.
The actual business test class I created is 99.5% identical to the one I would've made for .NET, only some minor changes that would easily be usable in .NET as well, just not as I would've made it before looking at Silverlight. In other words, it looks feasible to share business logic, provided I can make the base classes compatible.
Just so I'm clear, what I'm talking about is that I would basically have two project files, one for .NET, and one for Silverlight, but the actual C# source code would be the same, shared between the two.
So does anyone have any experience with this? Any tips or guidelines?
Will it be worth it? It certainly warrants more looking into.
It is definitely feasible.
It's done on a project here; the Silverlight project includes the C# ones, and there are some #IF statements handling some things (like log4net declarations), and other times things are just re-implemented. But in general, it's a huge win, and you should definitely attempt it (and certainly, we have, successfully).
-- Edit:
One point though, is that our OR/M (LLBLGen) didn't have inbuilt support for 'simple' objects to send down through Silverlight; but someone had written a plugin that handled it, which helped. So it may be worth considering what sort of DAL you're using, and how well it supports Silverlight.
What I've done to facilitate this is:
Frequent use of partial classes and #if !SILVERLIGHT to separate code into parts that Silverlight can handle.
Use of code generation whenever possible. For example I've been experimenting with T4 templates that generate Silverlight equivalent attributes (DisplayAttribute instead of DescriptionAttribute for example)
Whenever there's an interface/attribute that isn't implemented by Silverlight (such as IDeserializationCallback, ICloneable, INotifyPropertyChanging) I will create a dummy interface of the same name in the Silverlight application as long as I know that the fact that the implementation won't be used is not a problem.
Finally, it's worth noting that in Silverlight 4, the assembly format does allow for sharing of binaries between Silverlight and .NET as long as there are no dependencies that Silverlight does not support.
One more note about the separate base classes - it may be worthwhile to create an abstract class that derives from ObservableCollection in Silverlight and BindingList (or whatever you're using in .NET) to minimize the impact on your typed collections.
UPDATE
Today I was working on porting some .NET code to Silverlight that made heavy use of the System.Diagnostics API's like TraceSource, SourceSwitch, etc which do not exist in Silverlight. I created very minimal implementations of these in the Silverlight project and put them in the Einstein.Diagnostics namespace. In doing so I decided I needed a convention to easily identify code that was mimicking the .NET Framework vs. my own code. So I renamed the placeholder files to prefix them with an # sign. I also prefixed the class names in those files as well. The nice thing about that is that the # sign does not actually change their class names as far as the C# compiler is concerned. So #SourceSwitch still compiles to be Einstein.Diagnostics.SourceSwitch but in the code I can easily see something is up. I've also decorated these classes with a [SilverlightPlaceholder] attribute.
I do this with protobuf-net, and I use a few approaches:
conditional compilation symbols in the project file to trigger subtle code-branches (yes, it isn't perfect, but it works)
re-introduction of some things; attributes might be an example here - your code can still use re-introduced attributes, even if the framework code doesn't; as a more extreme example of this, for compact framework I had to re-introduce a good chunk of the Expression API, which was fun
just drop some things ;-p
However if you are using ITypedList (which you mention), I can see that whole approach falling apart pretty messily; component-model is complex enough already, without having to force your way through the hacks too. It really depends quite how far you've gone down this road. Maybe 4.0 / dynamic will open up some of these options again?
One possible fix to your issue is to copy the missing code from the Mono project. Back in the day, I did a small project with the Compact Framework and it was missing the entire System.XLM namespace. I just copied the entire thing from Mono into my project, compiled it and it worked great with minimal changes, iirc.
.Net is a huge framework with some functionality that appears to target beginners or becomes problematic if much customization is involved. So what functionality available in the .Net framework do you feel professional developers should avoid and why?
For example, .Net has a wizard for common user management functions. Is using this functionality considered appropriate for professional use or a beginner only?
One component/feature/class, etc per answer please so votes are specific to a single item.
Typed DataSets
ASP.NET *View Controls
ASP.NET *DataSource Controls
MS Ajax
jquery, and other js frameworks like prototype etc., are a more lightweight and flexible alternative. The MS Ajax controls may seem great initially, until you really need a custom behaviour out of the scope of the controls.
Microsoft themselves have recognised this to some extent in that jquery will be bundled with upcoming versions of visual studio, with intellisense support.
I think generally most controls/features that do a lot of work "behind the scenes" can cause a lot of trouble. No problem using a GridView if that layout is exactly what you want - but it very rarely is, and a Repeater is probably a better choice. UpdatePanels can save you lots of work if you want an ajaxy feel to your site, but compared with a jQuery AJAX call they - sorry to say so - suck. The user wizard you mention can be really useful during development, but if membership functionality is required in the project it should be built as an integrated part of it.
So in summary: Professional programmers should do the job themselves and write code that specifically satisfies their clients needs, and only take in ready made parts of the .Net Framework when that is in fact exactly what they need.
Thread.Abort
Here is an excellent article by Ian Griffiths about Why Thread.Abort is Evil and some better alternatives.
Remoting is generally a good one to avoid, at least if you're targeting 3.0 or above and can therefore easily host messaging endpoints in-process.
Linq To XML
XmlDocument/Xpath is easier to use, if you want strong typing to parse your document use xsd.exe or Xsd2Code.
EDIT
which one do you prefer ?
IEnumerable<XElement> partNos =
from item in purchaseOrder.Descendants("Item")
where (int) item.Element("Quantity") *
(decimal) item.Element("USPrice") > 100
orderby (string)item.Element("PartNumber")
select item;
or, with XmlDocument and XPath
var nodes = myDocument.SelectNodes("//Item[USPrice * Quantity > 100]");
.Net is a huge framework with some functionality that appears to target beginners or becomes problematic if much customization is involved.
It's the "appears to target beginners" that's the real problem.
Typed data sets are a great example. VS provides a nice simple UI to functionality that should be used only by rank beginners building extremely simple demo applications and experienced professionals who understand every nuance of the ADO.NET object model and what typed data sets are actually doing. Nobody in between those two poles should touch it, because there's a good way to learn every nuance of the ADO.NET object model and typed data sets aren't it.
Or take LINQ. It's seductively easy to write LINQ code without having a good understanding of IEnumerable<T>. But it's not so easy to write maintainable LINQ code without that knowledge.
You can think of .NET like an onion with many layers. For example the .NET compact framework is a subset of full .NET. Further there are "extra" layers on top on .NET in the form of "Extensions" which are optional installs for new features which have not yet been made part of .NET proper. An example of this would be when Microsoft released ASP.NET 3.5 Extensions which has now been rolled into .NET 3.51.
Another way to think of .NET is as a set of "libraries" you can use. For example there are a set or routines to support RegEx. If you want or need regular expressions, then you use these functions, if not you can simply ignore them. SImilary functions for things like trigonometry or security.
So I guess it really boils down to what do you need for your application? If you are doing scientific programming you may well want the trig functions. A graphical app will require functions that a console application would not. Web apps probably do not need to use the clipboard functions etc.
I really don't think there are any bad APIs in .NET, just programmers who use them in inappropriate ways.
There is lots to avoid in the WinForms library.
Avoid DataBinding to most standard WinForms controls. There are many bugs in that area which will lead to lots of head scratching. Or at least that has been my experience. NumericUpDown is a good example of this buggy mess.
Also avoid the standard WinForms controls when dealing with large datasets. They do a lot of data copying and can't deal well with large datasets.
Avoid ListView in "Virtual" mode as it is full of bugs.
In general I just recommend staying away from WinForms. If you have the option go for WPF or at least buy a good, well supported (and hopefully less buggy) 3rd party forms library.