Develop Reference

Is Workflow Manager 1.0 Viable?

The company I've been working on will develop a new project and in this project, Windows Workflow Foundation 4.5(we can't change it) will be used for process flow system which will be consumed by a web UI.
Our main use case is order payment which has multiple steps in UI and in every state transition, UI will notify workflow instance that if provided values are valid. If it is, it will persisted and so on. (like http://examples.donnywals.com/angular-splitform/)
It is designed as workflows will be hosted on IIS and every operation can be done about workflow(upload, delete, managing instances) should be accesible by a REST API. Also, workflow xaml files should be stored in database. Versioning, tracking and tracing and this kind of base operations should be supported too.
While searching about how to achieve this goals easily, I encountered Workflow Manager 1.0. I would like to use WF 1.0 but;
It lacks of documentation. For example, I don't know how to consume it's pre build REST API without WorkflowManagerClient and no documentation has provided. Where can I find good documentation about it?
Last update in WM 1.0 was provided in 2014 and it looks like no one is paying attention about it. Where can I find a roadmap?
It seems like no one is using Workflow Manager 1.0 without Sharepoint 2013. Has anyone been using it without SP 2013 and did you satisfied with the result?
I need to update previous versions of workflows instances to the latest if possible but I couldn't find a solution about this in WM 1.0. Only possible choise is terminating previous version's instances or previous version's instances is allowed to work in previous version of that workflow, not the latest. Hasn't it provided or only it's not documented?
Activities for WM 1.0(such as HttpSend, GetConfigurationValue etc.) which was accessible from Workflow Designer in Visual Studio 2012 is not supported in VS 2013 and VS 2015. We use VS 2015 and I don't think that we could use VS 2012, isn't there a way to use that WM 1.0 specific activities?
If I shouldn't be using WM 1.0, it seems like I can't use WorkflowServiceHost either because of AppFabric servers will not be supported after 2016. Is my only option is WorkflowApplication?
Every piece of information is welcomed, thank you.

we are using WFM without SP for a product the we are developing and deploying within Azure. What I can say is that you have to work a lot to target your needs with WFM, we are working on it from more than 2 years and still today we are facing problems to get results out from a wf! by the way I try to answer to your questions:
There is no documentation about consuming Rest Api without WFM Client; times ago I directly asked to WFM team without an answer...so we use the client...
There was an update this year ;) Cumulative Update 3
Yes, me!
It is possible to let previous version to run till their end. Next "start" request (both whit .Start or .PublishNotification methods) will start the new version
No way to use with version higher of VS2012...you need (like us) to build your own editor. There are a lot of examples like this
The reason why I choose WFM is that I didn't want to use WorkflowApplication and do everything by myself...that is (I think) the only option you have (of course WFM has also a lot of advantage other than "simple" persistence)
Hope to be helpful.

Prism architecture considerations for ClickOnce deployed applications

I'm creating a new application using Prism and ClickOnce, but while testing ClickOnce's hash checking for delta-only updates I noticed that I would need to make some architecture changes to take full advantage of ClickOnce updates.
To be clear, I am deploying to machines with poor internet connections and I really want to publish small, quick updates with minimal bandwidth. Ideally, only modules that have been modified would be sent over the wire.
First, I noticed that the client application project's hash (the one that makes the .exe) was always changed no matter what, and always re-downloaded. This lead me to remove Shell.xaml, ShellViewModel.cs, and some ResourceDictionaries and move them into a new ShellModule. This leaves AggregateModuleCatalog, Bootstrapper, App.xaml, and App.cs; each file is fairy small so this is fine.
Second, I noticed that ClickOnce's programmatic updating could go into a module, so I have that in a AutoUpdateModule.
Finally, my last concern is the Infrastructure project. Each module directly references Infrastructure, and if Infrastructure is modified all modules get new hash values. I believe this means that even if I add a line to an enum inside Infrastructure the whole app will be re-downloaded.
Is there an elegant solution to this issue? And if you've deployed Prism applications using ClickOnce what are some other architectural modifications that have helped or improved your deployment?

I'm unfamiliar with Prism, however, there is no way within ClickOnce to apply partial updates for standard applications.
I had a similar problem (I think) with a Windows app project that I was working on about 5 years ago. Specifically, my users often had spotty data connections (connecting over some times poor cellular data connections) and I needed to be sure that my updates were as small as possible.
Even though I could prevent the full application from being re-downloaded after each update, I did find that there were numerous, third-party dlls that never changed. So, I created a separate installer that placed those modules in the Windows GAC and they were installed only once, when the prerequisites were installed. This cut my application size down from 25MB to 2MB-- quite an improvement.
I'm not sure if this applies to your circumstance, but it might help.

Choosing CMS vs Portal vs MVC+Components?

I need some help figuring out whether it'd be a good idea to use a CMS or portal solution for my latest project, which is (currently) an ASP.NET MVC application that must serve multiple customers (being a company or some other entity with a list of users) from a single installation (that is, a SaaS solution).
In addition to the core functionality, which includes document management/publishing, I also need to provide basic social features (such as blog, forum, gallery, polls, etc.). However, it is imperative that content is only visible for the customer to which it belongs, and my evaluation of a bunch of CMS and portal solutions has shed little light on whether they support this. They're pretty focused on single-user installations, and documentation on how to integrate with an existing MVC solution is pretty thin.
Essentially I'm looking for some guidance to help me discard dead-end options (the product does not meet requirements, imposes too many restrictions, is not mature, etc.) and find unexplored options before getting too far ahead with the project.
My requirements for the architecture include:
Multi-site support (using a single domain for hosting)
Watertight separation of content between customers
Full integration across components/features
SSO (single-sign-on)
Single-site experience (shared header/footer, unified navigation, unified tags, etc.)
Ease of development and deployment
Custom logic will be written using C# and ASP.NET MVC and any products should support this
I want to stay in control
Solution should offer features but otherwise stay out of the way (for example, not force stupid idioms on me, like insisting on GUIDs for primary keys)
Active development community
No single-man efforts
Recent source control activity
Reasonable levels of documentation and maturity
Does not have to be open source
I have spent a fair amount of time evaluating products and components, which I'll briefly share here:
Umbraco
Does not support ASP.NET MVC (yet, as someone is bound to otherwise comment)
Great community support, active development
Seems to be lots of work to get started
Kooboo
No source activity (no updates for almost two months)
GPL licensed? (need something that allows for closed source applications)
N2CMS
Partial ASP.NET MVC support
Every customer must have a separate domain
Limited source activity (not dead but not vibrant either)
Orchard
Microsoft-sponsored (which means it's likely to be over-architected, code-bloated and slow, although it does have some well known and respected contributors/leads)
Built using ASP.NET MVC
Looks promising feature-wise (but is unlikely to be stable at this stage)
AtomSite
Feels reasonably mature and has decent documentation, albeit with holes
Built using ASP.NET MVC
Limited source activity, single developer
MojoPortal
Looks good for a portal, but probably requires custom logic to be built as modules around the product (I was hoping to avoid that kind of lock-in if possible)
DotNetNuke (DNN), CommunityServer and Microsoft Office SharePoint Server (MOSS)
Definitely not my cup of tea ;)
BlogEngine.NET
Mature and feature-complete
No ASP.NET MVC support
Integration possible but not without lots of Web.config voodoo
Not sure if it supports customer separation
Given the list above I'm leaning towards AtomSite, N2CMS, Orchard or BlogEngine.NET. If I go with the latter I'll be using jitbit AspNetForum, which is a great match for my needs.
I'd probably prefer to use a custom ASP.NET MVC solution and individual components as this is likely to give me the greatest amount of control, but on the other hand, it'll make site theming and integration harder. What combinations have you tried, what worked well and what didn't? Anything important I'm leaving out of my evaluation? Any other relevant advice?
I'd appreciate it if the answers were not simply endorsements of your favorite product or way of doing things, but something that would help me choose or eliminate solution candidates given the requirements outlined above.

With the level of requirements you've specified, I'm personally going to have to lean towards the custom approach. You can hire someone to do the design (view) portion of the site for you, or you can buy a theme off the internet from site designers and customize it to your liking. (Sometimes just having somewhere to start is enough for intermediate level customization).
Multi-site support (using a single domain for hosting)
You're probably going to want to have control of your hosting environment, either a VPS (Virtual Private Server) or a dedicated box. This is still possible on shared hosting but not reccomended.
Watertight separation of content between customers
You'd probably have to spawn a unique app-pool for each customer with thier own services user for 100% seperation.
Full integration across components/features / SSO (single-sign-on) /Single-site experience (shared header/footer, unified navigation, unified tags, etc.)
This is going to be the tricky part. This Example may have some useful insight for you in the development process, but you're going to want a unified login service and have all sites use it or link to it.
Ease of development and deployment
This is where it gets tricky. Development ease comes from your background I think. MVC is definately the right choice in this respect then, knowing a lot about the right ways of going about building a site in MVC will aid in this process. Keep up to date by reading community blogs and listening to podcasts like Hanselminutes or DotNetRocks will help keep you in touch with the newest and greatest tools/technologies for making your site get off the ground quickly and effectively.
Deployment is the tricky spot. MSDeploy still isn't quite there. But if you can you probably will want to come up with a Dev -> Staging -> Release publish structure so you can test your code in a staging (mimiced production) environment.
Custom logic will be written using C# and MVC and any products should support this
I want to stay in control
If you develop the site in ASP.NET-MVC, you'll be able to build common libraries that you can use not just in your site, but also in your custom tooling. This will greatly reduce your code duplication and helps make sure operational unity is achieved. (Everything works the same way).
Solution should offer features but otherwise stay out of the way (e.g. not force stupid idioms on me, like insisting on GUIDs for primary keys)
While you'll have control in this situation, I'd strongly reccomend GUID Primary Keys. This allows Merge Replication, which can help you easily restore backups or use failover DB servers when things go awry.
Active development community
.NET has a great community out there, (including this one) and you should get lots of support if you ask for it politely.
No single-man efforts
Not sure what you mean here, You'd be the Single-Man unless you hire help, but even 2 people can do great things given a little time. Even one-man can do great things, but the framework you're running on here is backed by a commercially funded huge team.
Recent source control activity
Doesn't really apply to .NET, but a lot of the libraries that you may use (NHibernate, MVC Contrib, AutoFac, Etc...) will have lots of activity and constantly being improved.
Reasonable levels of documentation and maturity
.NET and most of the production level libraries developed for .NET (Mentioned above) actually have a pretty good degree of documentation. There's multiple paid & non-paid sources of information for .NET alone, and most libraries (are well supported by the community and known on StackOverflow)
Does not have to be open source
Look for support libraries that are LGPL (i.e. you can use it in commercial software, but if you modify the library you have to release the new library code if you release the binary.) You're pretty safe here, your site dosen't have to be open source if you use these libraries to support your development.
Well, that's my 2cents. The project you've described is no small job, you're looking at a considerable amount of work even if you go with a pre-built solution (mainly hacking it to work the way you want). I imagine your biggest hangups would be SSO & Security for the pre-done solutions. Not to say it's impossible, just tricky and the end result may not be exactly what you're looking for.
Also, look into OpenID, it may be the best solution for linking all your sites together and most pre-built systems can easily be ported to use it.

Take another look at MojoPortal. The CMS is awesome and the main developer , Joe Audette, is very responsive. I'm have several installations of the CMS running single and multiple sites.

I would lean towards a CMS based solution. Having a tested and production ready software not only reduces the development time but also helps in continuous upgrade and reduced bug count.
If you go down this route, you may want to also consider Sitefinity. Not only does it support all the features required by you, but also is built on .NET and supports MVC development. The product is built by Telerik, the makers of UX tools.
Disclaimer: I am employed by Telerik.

I've recently come across phpFox which is a social networking/forums/community site CMS. This may be of use to you and is fairly inexpensive.

The solution for the site of our company has become EBIZ CMS: full-featured site that includes social networking, online store, features a presentation, a forum, create HTML pages and much more, including the maintenance of professional technical support, so we do not even need help for installing by a programmer, and it is only US$ 9/month!

Porting existing code from C# 2.0 to C#3.0 and .Net 3.5 (possibly .net 4.0)

Our one and only enterprise application suite has been developed over last 3 years using C# 2.0 on .Net 3.0. We use winforms and WCF heavily. The development tools is VS 2005 Pro / TFS 2005 / Resharper 3.1
As technical lead I obviously understand the benefits in a move to C#3.0 and .Net 3.5. But I want to convince management for a move to C#3.0, .Net 3.5, VS 2008 and TFS 2008. They will obviously be interested in things like productivity, cost, quality etc. Please suggest me some ideas on how best to make my case.
Given that this may not happen till mid next year am I better off to hold till VS 2010 and .Net 4.0 is out.

"If we don't upgrade to newer technologies, it will be more difficult to hire good developers, and those who we already have will be fleeing soon... probably including myself..."

Is there much in .NET 4.0 which will benefit you? C# 4 itself doesn't have many new features... whereas I'd expect you could make good use of the C# 3 features. .NET 4.0 does have some very cool things (in particular Code Contracts and Parallel Extensions) but you should really look at what you would use.
If management is nervous about changing framework version, you could upgrade to VS2008 and use C# 3 but still target .NET 2.0. (Most of the C# 3 features still work when targeting .NET 2.0.) Using LINQBridge you could even still use LINQ to Objects, which is hugely beneficial IMO.
Of course if you can upgrade to .NET 3.5, you'll clearly get more opportunities for LINQ goodness, etc.

Whip out the Microsoft expiration schedule on technologies, figure out how long your current solution set will be supported.
Look to things like Linq-to-Entities. If you don't currently have an ORM, this is a huge time saver.
It's always easier to upgrade version by version than it is to jump several versions. I learned this over time. Step by step upgrades were almost always painless. Upgrades that jumped multiple versions required a signficantly larger amount of extra code and testing.
Identify the top 5 features in your "nice to have list". How many of them are only provided by, or provided in a better way, by the new version?
Don't push for bleeding edge. There's a cost to being on the very edge of emerging technology. That cost is often very hard to justify from a business standpoint.
You have change code anyways. Figure up the cost of the next X feature changes. Try to roll it into a release. "We can do it as part of XYZ release with only NN extra hours, saving MM hours over the next six months".
Look around the web for stats on code rollover. Most custom systems are "rewritten" gradually over time as the business process changes. However management tends to view software as a "write once, use forever" endeavor with only some maintenance costs. Make sure they understand that this is them taking control of the upgrade process, and them guiding the future of their tool in a planned fashion, as opposed to just whatever comes out after dozens of minor changes.
Edit: This all assumes that there actually is a cost justification, which you will hopefully answer for yourself while going down this list.

I don't think any productivity gained by going from C# 2.0 to C# 3.0 can be easily justified for a particular project. Rather than try to justify moving to the new version of the language, think about why you wouldn't?
Does the group want to stay with VS2005 forever, or are they planning on moving to VS2008 some day. If they want to stay at VS2005, consider the fact that that compiler is now on extended support, pretty soon it won't be supported at all, and you won't be able to get even security updates, similar to VC6. Furthermore, the new version of Microsoft's SDL (5.0) requires the use VS2008 or later.
If the group is willing to move to VS2008 eventually, then determine if you can work in a mixed mode environment. This can work effectively if you have a large code base, so new components are built with the newer tools.
Once the team / project has moved to VS2008, then using C# 3.0 features as opposed to sticking to the C# 2.0 subset shouldn't really be an issue.
For VSTS, the best thing to do is to try to use it on a new project.

You will have to upgrade from C# 2.0 to get LINQ. This technology is very powerful, not only for querying databases, but for development in general.
Upgrading should (at least in theory) be easy. You recompile and pay attention to warnings about obsoleted calls.

The biggest problems I've ever run into when trying to upgrade an enterprise application and convincing management was because of the deployment cost. When you upgrade to .NET 3.5, all your clients will have to get the 3.5 framework. Depending on your end user audience, this could be a big deal. That was the holding factor for management whenever we tried to pitch it. The language features, framework features, and other benefits/costs really didn't matter much to them. The deployment cost kept ringing in their ears. If you can make the deployment cost minimal (i.e. you might roll the 3.5 framework into the next install or something), then you'll probably be able to show that the productivity benefits far outweight the costs. Otherwise you might find yourself in the situation I found myself in.

Is Mono stable and fast enough? [duplicate]

This question already has answers here:
Is Mono ready for prime time? [closed]
(17 answers)
Closed 8 years ago.
C# looks great because it is a compiled language which seems to run quite well without too much CPU and does not consume too much memory. And StackOverflow and ServerFault are good examples of an MVC/.Net/C# stack that scales.
C# is also interesting because despite being compiled, it still has a lot of advanced features as a language only found on slower interpreted language.
My server being Linux only (Ubuntu 8.04 LTS), I am wondering if installing Mono in place of the .Net framework is a good idea for production use.
I currently do not have any existing applications using .Net but I am interested in using existing frameworks (like MS MVC).

Stable enough and fast enough to do what?
It will have different levels of stability and performance depending on what you want to do, I'm sure. For example, one of my Protocol Buffers unit tests (which uses Rhino.Mocks) manages to make the Mono VM abort with an assertion error - but I have no idea (currently) of whether that would affect anything else I'm doing, or whether it's just related to the form of proxying being used.
I suggest you try it and see.

ASP.Net MVC is now open source. That it is now integrated into MonoDevelop via an add in would suggest that you are likely to get things working.
Given the very new status of this you should expect issues. This blog should be a reasonable starting point for you.
Remember that many ASP.Net MVC tutorials assume you have a sql server back end, this is unlikely to be feasible (given your question) so bear that in mind.

You'll have to judge it on a feature basis. At my current customer we're running a high-volume document processing and delivery system written in .NET 3.5. We have a Linux server that runs Mono with .NET components that take care of the delivery of documents to the outside world, e.g. through FTP. That runs fine in production.
We did run into a problem with the Mono implementation of the .NET FTP component, which forced us to look for other third party .NET components, which solved the problem. So you might run into things like these. But in our case: once we got it to work, it worked just fine and stable.

I think that Mono is REALLY stable and complete.
It brings .NET to *nix World.
In my company I'm leading a project aimed to build an automated machine. This machine is built by different devices that need to be governed using a serial interface (RS232).
The machine exposes a touch screen for user interaction.
One of my responsibilities is to project the logic of the system beyond the GUI application.
I've chose Mono (used for presentation layer) also to build a custom middleware that runs the application business logic.
This middleware is some sort of application server and it's executed in Ubuntu 10.04 LTS.
For now all the system is an advanced prototype, but also the final product will keep its heart in the couple Linux/Mono.
I hope that these considerations could be useful for you.
Regards,
Giacomo

as i had read on mono project wait for MONO 3.0 it will solve the main problem in mono means memory leakages and garbage collectors so before 3.0 we can't say it as stable but it is a life line for developers like us who want to develop platform independent s/w with dot net.