Disadvantages of implementing InfoPath in SharePoint

Question

I need to know Limitations of implementing InfoPath forms in SharePoint before I deploy it. Can someone please help me out?

Answer 1

All Infopath disadvantages are counterparts or well-thought intentional Microsoft's architectural genial decisions.

For example, unavailability of Infopath template projects in Visual Studio 2010 is for common's good to leverage common platform and independence on versions of tools founded (or continued) by Infopath Designer 2010's VSTA restricted back to .NET 2.0 and Visual Studio 2005 Tools for Application

Read:

• "Visual Studio 2010 does not include the InfoPath form template projects that were provided in previous versions of Visual Studio. You also cannot use Visual Studio 2010 to open or edit an InfoPath form template project that was created in a previous version of Visual Studio. However, you can open and edit an InfoPath form template project by using Visual Studio Tools for Applications"
  in msdn's InfoPath Solutions

• "We want everybody who works with InfoPath 2010 to be able to leverage all three versions of our managed OM, the optimized design experience, and the best publish story from a single development environment that ships with Office; VSTA is that story"
  in comment-reply to msdn blog Microsoft InfoPath 2010

So, any disadvantage of Microsoft technology is just misunderstood or unappreciated genial and innovative advantage

Update:
If to speak seriously, the biggest disadvantahe, pitfall and trap of Infopath, amongst many, is that it is next-to-impossible to explain to your stake-holders (colleagues, customers, users, employer, web-developers et al) that Infopath forms are not web pages are not for developing web pages and Infopath Designer is not the developing tool for creating or modifying web pages

Infopath Designer is the tool for creating XML-based forms, i.e. XML data for forms and their content, which can be used by Sharepoint server as mostly uncontollable by developers add-ins for generating web parts and New/Create/Insert-Edit/Update/Modify-Display/View pop-ups/modes to web pages as very limited and mostly uncontrollable for development components while their most power and flexibility lie in client (non-browser-based) forms.

Answer 2

Like any tool, the solution should depend on the problem you are trying to solve.

I believe its root intention was for an electronic forms tool with templates that could be easily created by regular information workers, and not required to be developed by "programmers" who would do regular web forms in ASP.NET. I think its a great tool that definitely has some great uses.

Where it has perhaps come up short is end users hardly ever build forms. Instead they are built by either developers or developer-like people. The developers tend to come up with sophisticated solutions that may or may not be best suited for the technology. As an example, I have a pretty strict edict that says "never add managed code (.net) to an InfoPath form" since it complicates the deployment and management of that form with SharePoint. At the same time, many aren't so strict and do that.

Given a given problem, I work with my clients to find the right solution. Sometimes it is InfoPath, sometimes it is not. Within a given organization, there are likely reasons to use both approaches depending on the specific problem.

Answer 3

• One limitation I had to deal with when working with IP forms was the limited set of controls. Compared to ASP.NET, the IP control are very limited. Many times I had to find work around. If you design the IP form to open up in the browser you will yet get more restrictions.

• I also agree with @Mark that introducing code behind for the IP forms will complicate the maintenance and the deployment of the forms.

• Since IP form development is different than ASP.NET forms, you need to learn it.

But, taking into account all the IP limitations, there are many situations were IP forms is the wise decision.