It takes at least 7 assemblies and restricting my AddIn's data model to data types that remoting can deal with before the appdomain isolation features begin to work. It is so complex! The System.AddIn teams blog implies to me they were trying to re-create a mental model of COM, a model I never understood very well in the first place and am not sold on the benefits. (If COM is so good why's it dead?-rhetorical question.) If I don't need to mirror or interop with legacy COM (like VSTO does using System.AddIn), is it possible to just create some classes that load load in a new AppDomain?
I can write the discovery code my self, I've done it before and a naive implementation is pretty fast because I'm not like iterating over the assemblies in the GAC!
So my specific question is, can I get the AppDomain isolation that AddIns provide with a few code Remoting snippets, and what would those be?
I'm not entirely sure that that any answer to your question meets the terms of the site - there is no solution.
Yes, remoting is easier as it is done for you. However, it is highly controlled and as you identified, requires a little work to plumb it all together. The cache file spewed out by the discovery process is hardly welcome either.
System.AddIn excels at isolation, which is actually a bit of an arse to put together from scratch in a robust, flexible way. It supports cross process hosting and fairly simple passage of user WPF elements from one domain to another.
One thing to remember however is that MAF's target audience is not those who are trying to connect two applications together. It is targeting developers wanting pluggable yet secure systems (cross process hosting protects the root application from unhandled exceptions, appdomains allow for executing potentially foreign code with defined security). From most communication, direct yourself straight towards System.Runtime.Remoting or WCF.
If you want to continue with System.AddIn, consider the pipeline builder plugin for visual studio!
In conclusion - you can get System.AddIn isolation using Remoting but to get a decent system you will require more than a few snippets. I am trying to replicate it myself and am tripping up all over remote interface component - something System.AddIn does without a hitch.
After messing around with System.Add for quite a while, I'm convinced that it was added as a one-off special purpose solution for Microsoft use. I'm surprised it got elevated to a core part of the .NET framework. It doesn't seem to have the refinement and polish needed for a general .NET framework component.
I'd like to find an alternative way to create .NET managed add-ins that doesn't require so much effort.
Related
We are currently developing for one of our clients in classic interface. A lot of development has been done so far with classic interface and some of tasks are still under development.
There are lot of functionalities, which use Xrm.Page directive too.
Now, our dilemma is, should we move the client to Unified Interface at this stage and validate all the developed features again at new UI.
OR
Should we continue with the classic one, do the GO LIVE for the client at the end of this year.
Could anybody advise on this, any help would be much appreciated.
The UCI is a big change and will break functionality that used to work in classic such as Xrm.Page and DOM level changes, as you say.
Without having full knowlege of the scope of the work I can't offer you answer on this but what I would recommend is to read the official Microsoft paper on the Unified Interface Playbook http://download.microsoft.com/download/A/F/3/AF3D45A7-4F38-41BE-8956-1DF7A4A5AFDB/dynamics365unifiedinterfaceplaybook.pdf
I would recommend taking into account the scale of the change (how much work to remove relience on Xrm.Page and DOM code?), the most important task is to ensure nothing breaks on go live. If you have time do move to UCI with sufficient testing in place then do, as the classic interface will eventually be deprecated and not work - although Microsoft tend to leave lots of time for migration for big features such as these.
I'm working on a very large project and have adopted the hybrid strategy by creating distinct apps for certain job roles and leaving some of other underused and less businsess critical functionality in the old classic interface due to not having sufficient time to test and deploy. This will get migrated once we have sufficient resource to complete and test this.
For users it can be quite a paradigm shift, but can be turned around into a positive once they see and understand the benefits the UCI interface brings and its in use.
I will start working on a Project soon, and as I am a noob in regards to coding (and general indecisiveness due to the lack of knowledge), I would like to have some suggestions in regards to what type of Windows (forms) application I should build (eg. payroll system, library system, etc)
I know there are a lot of ideas out there, but I would like some suggestions of an easy system to build, including a system that is easy to expand on. Will also make use of a database (connecting SQL Server to the application)
I will be using .NET / C# (VS)
Thank you in advance.
In my experience 90% of the commercial systems I've been hired to write just involve relatively basic storage and manipulation of data with some layers of security around access.
Maybe start with something like a payroll system, but keep in the back of your mind that you could scale to accommodate a full HRMIS (Human Resources Management Information System). Also, experiment with ASP.NET MVC and Web Technologies, in my experience, the majority of systems now are moving to a web-based implementation.
The possibilities are endless in the world of software development.
You could make a winforms program that calculates all the primenumbers between two user inputs. You could also then output these to a XML-file, and make a button that lets the user open an XML-file and reload whatever they input back then.
It's pretty simple, but still involves some Winforms basics and some XML data storage/manipulation.
Has anybody replaced COM+ with WCF?
Was there an improvement in the performance?
What were other advantages?
I have used both COM+ (plus COM and DCOM) and WCF for years each. This included building large airline reservation systems using both technologies.
WCF and COM+ a really two different beasts. COM+ was really built for the COM heyday. As such, it is really easy to use in any environment that plays really well with COM (like VB6). In those environments you cannot beat it for development ease and performance. COM+ also gives you lots of "freebies" such as transactions. We used it for many years and were very happy with it. Performance was also very good.
COM+ can also be used in dotNET, but I never felt it was a first class citizen. I always got the feeling that Microsoft was supporting COM+ in dotNET because they had too. It always felt a little clunky to me.
WCF is a dotNET beast. The big advantage I see to WCF is flexibility. You can pretty much plug in, or build, any communications protocol you could possibly want. Want ease of use, use HTTP. Want objects as tight and performant as possible, use TCP and Binary serialization, etc. It plays well in the dotNET world. WCF has a ton of features available "out of the box" as well, like transactions, queueing, secure channels, load balancing and more. But you have to configure it to use these features with config files that are very complex and cryptic. In COM+ most of these were just checkboxes in component services.
Regarding performance. I always found COM+ to be really fast if you followed all the rules (call SetComplete when calls done, don't maintain state, etc). WCF can also be super fast, but you have to make sure you configure it correctly. WCF lets you configure EVERYTHING. This can be really great, but it also let's you make messes of things really easily. The biggest hit you will get in WCF is probably your object serialization (at least in my experience).
As I said, WCF is super flexible. You can use it through firewalls and across the web or private WANs without too much difficulty. Try doing that with COM+ (good luck, I've done it and it is NOT easy). We used WCF to setup communications between airports over private communications networks all protected by different firewalls owned by different parties.
Really, if you want some of the goodness of WCF without all the pain, take a look at WebAPI (http://www.asp.net/web-api). They started by building it on top of WCF as a way to get WCF up and running easily and quickly. But I don't believe it is tied to WCF any longer. That being said, it does not offer all of the features of WCF and if you need these advanced features you won't be able to use WebAPI.
In my company they are finally (about time...) considering to convert one of our best selling apps from a 2-tier to 3-tier architecture, both on logical (Presentation, Business and Data layers) as well as physical level. Probably we will go for either a Delphi-Delphi-Oracle or a Delphi-Java-Oracle approach for the change.
This is a relatively old and large app that has been created and modified for a long time before I began working there. Refactoring, except for when something had to be changed, was usually never considered. Also, business logic is present in both of the actual tiers... sigh.
The physical change does not bother me much but the logical change will be kind of a passage through Hell. In order to smooth it as much as possible I would like to investigate about which Delphi components suit better for a 3-tier model.
¿Which alternatives would you consider to use?
Another good n-tier framework library is kbmMW from components4developers: http://components4developers.com/
We've recently converted our 2 tier Delphi app to 3 tier using RemObjects DataAbstract. While the initial learning curve was quite steep, we are absolutely delighted with the results.
DataAbstract lets you forget about the underlying nuts and bolts of database and network connectivity and concentrate on the business logic. It allows you to create an abstract service layer that provides your server clients with a nice API. Using this API we connect to the server using both a Delphi and a Delphi Prism ASP.NET client.
I've found RemObjects pretty usable. They have also DataAbstract built top on it, but I haven't used it.
Have you ever considered DataSnap XE?
I'm starting to develop a Windows service. I want to use some classes from my own, that has little dependencies to some MFC classes like CString, CSocket, CArchive, CMemFile and CObject. MSDN says you need to be very careful about which pieces of MFC you use in the Windows service, but don't specifies it and don't describes the problems that can occur.
My questions are:
what pieces of MFC can be used?
what problems can I expect, by using MFC?
which parts of Windows service are critical for MFC use?
is it advisable to use ATL instead of MFC for Windows service?
I'm not sure what they mean in teh MSDN article. As long as you don't use any of the GUI functionality you'll be fine - but that's a general design issue when developing services.
That being said, ATL has functionality specifically designed for building services IIRC so you may be better off using that.
To answer your questions (to the best of my knowledge):
1) the ones you specify are no problem.
2) I guess they mean synchronization issues with UI components. As long as you don't use any CWnd-derived classes you'll be fine.
3) don't understand the question.
4) See before, plus ATL is more lightweight so you'll have to distribute less, and provides build-in functionality that'll make it less of a pain to develop the service. See e.g. CAtlServiceModuleT. You'll still be able to mostly use your own classes, as CString is shared between MFC and ATL nowadays and ATL has classes for socket programming and memory file mapping itself. It doesn't have an equivalent for CArchive, and I'm not sure what functionality you use in CObject so I can't say whether there's an equivalent in ATL. So to conclude, I'd say 'yes' to this question.
(I know this answer is a bit late and this question was already answered but MFC in services is a sore spot for me...)
CSockets, far as I recall, require a Window. It makes an invisible one in the background. I found out this the hard way when I tried include some pre-exisiting MFC code into a windows service. Maybe this was only required if you accepted socket connection - I can't recall? But it did not work! (How exactly I wasted so much time doing this w/o realizing this limitation is a long story)
CObject? If you need the runtime class id stuff use RTTI (dynamic_cast, etc...)
CString, I like CString, I know it's shared with ATL now, not sure if you pull it in w/o MFC or ATL included... You could use std::string. Also, I recall someone created a derived std::string that provided the same methods as CString.
(EDIT: found the code - man!! that's a blast from the past...)
CArchive, CMemFile: do you really need these?
Anyway, as Roel said, ATL may be more helpful. I wouldn't use MFC in a server-side application (ever!) ATL? Maybe. If I needed COM, defiantly. No COM but for CAtlServiceModuleT, etc... maybe....
And another bad thing about MFC in services that I have just experienced while trying to turn a regular MFC-ATL app into a service: The use of AfxConnectionAdvise() is actually useless without a Window procedure. The threads in my service are just regular non message-pumping threads. I believe this is why I never get events fired from another COM server I have developed. That other COM server hangs on Fire_xxxEvent(), causing a big mess in the whole system.