我们的组织大约在两年前开始使用 SharePoint 路径。在此之前，我们（开发人员）主要为 SQL 后端编写 asp.net 前端。现在似乎每次出现新项目时，我们都被要求“使其”适合 SharePoint；由于复杂性和与其他技术的交互，我们在 SharePoint 中塞入了一些可能应该是独立应用程序或 Web 应用程序的东西。
我的问题是：对于在 SharePoint 和 Web/Winform 应用程序中开发项目，您在哪里划清界限，您如何让您的经理相信 SharePoint 可能不是特定项目的最佳解决方案？
我有点同意你的看法，这有时是一个棘手的问题。不过，总的来说，我同意陈词滥调，即您只需要稍微不同地考虑共享点应用程序即可。如果您的数据可以被认为是基于列表的，那么 SharePoint 可能不一定是一个糟糕的开发框架。从表面上看，这似乎是更多的工作，但 IMO 的挑战只是从一个地方转移到另一个地方。如果您使用自定义字段模板和 Web 部件之类的东西，您可以相对自然地处理各种数据。您还可以免费获得 SharePoint 的积极方面（已经成熟的安全框架、内置搜索、网站和列表模板/定义、个性化页面自定义、yada、yada）。
我也不知道你在这里所说的“复杂性和与其他技术的交互”是什么意思，所以很难想象当 SharePoint 添加到组合中时可能会引入哪些具体问题。
如果您的开发团队在 SharePoint 方面相对缺乏经验，并且您关心质量和截止日期，那么我绝对可以理解您的观点。这不是一个简单的学习曲线，但我认为 SharePoint 产品比许多人认为的更自然地可扩展。
在某些情况下，SharePoint 应用程序和 ASP.NET 应用程序之间存在第三种选择。您可以构建自定义网站和应用程序页面并将它们部署到 SharePoint 网站。（Inside Windows SharePoint Services 3.0 一书很好地概述了如何执行此操作。）这将允许您在 SharePoint 环境中使用 ASP.Net 和 SQL Server（这意味着您还可以利用诸如 SharePoint 安全性之类的东西）。它不像开发一个普通的 ASP.Net 应用程序那么容易，但它是一种折衷方案。
当然，如果他们希望这些新应用程序建立在 SharePoint 技术（列表、库、工作流等）之上，而不仅仅是“在”SharePoint 内部，这在某种程度上是一种技术性问题。
One of the primary reasons why you might put an applicaiton in SP is when you want to take advantage of the building blocks SP gives you:
尝试将新应用程序“集成”到现有池中时要考虑的一件事是，数据（客户、库存等）是否有任何重叠会从合并中受益。
能够在一个地方备份多个应用程序及其所有各自的数据还有一个好处。
为什么他们要求将所有内容都纳入 SharePoint？
以我的经验，这是因为'ole SharePoint Intranet 作为一个门户非常棒，可以将所有内容放在一起并在一个信息架构下可以找到。
从对组织中应用程序空间的使用感知来解决问题。
只要应用程序看起来和感觉就像 Intranet 站点的一部分并且用户不必考虑如何访问它（以及如何退出），您几乎可以做出任何必要的架构决策来获得在实施和维护方面，组织的最佳收益。
当我们开始考虑较少从 SharePoint 与其他东西到信息架构、可查找性和可用性等漂亮的毛茸茸概念的网站时，我们决定不在 SharePoint 中实际使用它，但仍然像 Intranet 一样对其进行皮肤变得更容易销售。