2015年12月8日,星期二

PowerApps–与Office 365,SharePoint,SQL等通信的无代码Azure应用

PowerAppsare a new way for power users to create valuable business apps, which connect to enterprise data and work great on the PC and mobile devices. I agree that it has the potential to be a big game-changer in terms of what the Microsoft stack offers - some other services have similar app 建造 platforms, but Microsoft have a pretty big vision here. 的key goal is to facilitate end-users to build applications, but perhaps in contrast to previous approaches, the resulting apps also sit well with I.T. needs –它们与Office 365和Azure集成在一起,安全且能够根据需要进行扩展。

My interpretation of what PowerAppsprovide can be summarized as:

  • 无需代码即可快速构建应用。 But in this, 您 have choices - apps *can* call out to custom code if required (a web API hosted in Azure – and this 做esn’不必是.NET API,也可以使用其他语言)
  • 能够连接到许多数据源,包括本地数据。 这些包括SQL Server,SharePoint列表/库,OneDrive,Dropbox,Google Docs,SAP,Oracle,动态CRM等。有趣的是,’也是使用Excel文件作为数据源的选项–它存储在OneDrive,Google文档还是Dropbox中
    • 这些数据连接可以存储在一个库中,因此高级用户可以轻松使用它们而无需关心基础细节。
  • 用于构建用户界面的设计图面/画布。 Think InfoPath on steroids, but with support for more than just 形式. For example, it should be easy to create an interface which presents data in a grid, with 充分 support for CRUD operations (create/read/update/delete) –有效地支持它的屏幕/页面是自动生成的。
    • 设计经验还包括一组控件–列表框,按钮,滑块,下拉菜单,图像,不同类型的图库(例如,文本/图像或 同时包含)等内容,甚至包括用于移动设备的摄像头控件
    • 控件本身就是HTML和JavaScript– and I’d期望有某种用于创建新控件的可扩展性模型
    • 除了控制属性,’s一个表达式框,允许您键入伪代码(例如,将控件绑定到数据)。这比简单“real”编程,但仍可能需要一定程度的技术理解
  • 可以从模板创建应用. “Event signup” and “opportunity template”有几个例子可能是一个很好的起点
  • 应用双色球推荐一注和API托管在Azure中。 它们是Azure AD应用双色球推荐一注(因此它们可以被保护并提供SSO)。就应用双色球推荐一注的运行位置而言,可以选择托管在Microsoft管理的“PowerApps cloud”(这是一项多租户SAAS安排,“Free” and “Standard”计划)或在您自己的Azure App Service环境中(“Enterprise” plan) – see //powerapps.microsoft.com/en-us/pricing/ 有关更多详细信息
    • 的re will also be some governance and management capabilities, especially on the 企业 plan
  • 简单分发到移动设备。 我的理解是 a native PowerAppsapp for 所有 of the major platforms 例如iOS,Android,Windows Phone等。用户只需在商店中安装一次,或将其推送到托管设备(例如InTune)。 *您*的单个PowerApps然后可以在此应用双色球推荐一注中打开–换句话说,任何可供用户使用的应用都会显示在某种应用列表中(例如,费用应用,客房预订应用等)

体验始于构建过程–我可以从创建一个整体应用双色球推荐一注或创建逻辑流程开始:

有一次,我’已经启动了我的应用双色球推荐一注,我可以创建不同的 屏幕和decide whether each is designed principally for a tablet/phone. I can also choose from a series of templated layouts:

然后,我可以开始将控件添加到设计图面:

在任何时候,我都可以运行我的应用双色球推荐一注并开始对其进行测试–在下图中,’一个绑定到某些数据并具有用于显示所有项目的屏幕的应用双色球推荐一注。每个项目旁边都有一个编辑链接(箭头),可将用户带到另一个屏幕来编辑该项目:

在管理和访问方面,PowerApps由Azure支持–具体来说,它们在Azure AD中注册并托管在Azure App Service中。

这意味着您可以选择利用Azure App Services的所有优势。可以将它们作为一个单位进行扩展,以满足您的任何需求,可以使用Azure AD保护Web应用双色球推荐一注部件,从而实现单点登录,并且那里具有用于托管Web API的特定支持功能。

深层发掘

So, hopefully 您 can start to visualize 怎么样 a data-driven app can be created, and what it might look like on a mobile device. 如果你 can 想像 that being the employee feedback app, the performance review app, the 发动机er scheduling app, or whatever the simple killer app for 您 or 您r client is, even if it’只是通过SharePoint列表或Excel中的数据提供支持,希望您可以看到PowerApps的潜力。

有关PowerApps的更多信息即将发布。该服务是’t live 在 the time of writing, but 您 can request access to the preview 在 //powerapps.microsoft.com/

如果你’d想在此阶段阅读更多内容,我建议:

还有更多!

2015年12月3日,星期四

SharePoint协作,Office 365组,用户配置文件,PowerApps等方面的增强功能! (2015年底)

最近,我在Redmond与Microsoft一起度过了有趣的一周,听听有关Office 365和SharePoint未来计划的详细信息。虽然我可以 ’为了共享大部分信息(属于NDA),Jeff Teper和Bill Baer确实在上周的斯德哥尔摩欧洲SharePoint会议上公开宣布了一些细节,随后又公开宣布了一个大项目PowerApps。我曾在斯德哥尔摩做过几次演讲(为此,’不久将发布幻灯片组等),很高兴看到其他项目的一些细节出现了。这里’s my summary of what’s coming:

  • SharePoint 2016公共Beta版-现在可用
  • Office 365中用户配置文件的增强(Delve配置文件)–一些功能是演示’d,下面有一些屏幕截图
  • SharePoint协作和团队网站的增强–我认为这是*大*
  • OneDrive for Business的增强功能
  • Office 365组的增强功能
  • PowerApps–支持移动设备的高级用户创建业务应用双色球推荐一注的新模型
  • 其他增强功能–更好的外部共享,以及对Office 365 / SharePoint混合的改进

让’详细浏览每个项目。

SharePoint 2016公开测试版

Bill Baer重申SharePoint 2016主要是“专注于基础架构”发布。头条新闻是对混合设置和运行本地环境的一些改进,例如新的MinRole服务器配置,Cloud Search Service应用双色球推荐一注,对用户配置文件同步,DLP的更改以及对规模和合规性的改进。但是,与以前的版本相反,组织应该 期望最终用户功能发生重大变化或出现新变化。是的,Office 365带来了一些调整–用于全球导航(包括跨本地/在线站点)的可扩展应用启动器,以及一些移动改进。但是在现阶段新的最终用户功能方面,并没有什么大不了的。有趣的是,’排除以后可能会进行更重大功能更改的可能性–微软正在寻找带来“frequent update”从Office 365迁移到本地SharePoint,以供需要的组织使用。例如,这可能是一个选择加入的模型,但它不仅可以用于常规补丁,还可以提供全新的体验和功能。

Office 365中用户配置文件的增强(Delve配置文件)

Office 365中基于人员的功能有一些不错的添加,主要是对Delve用户配置文件的增强。在欧洲SharePoint会议上显示了一些示例(下面的屏幕截图),但是我相信目前还不能保证所有这些想法都一定会发布。所以,尽管你’在这篇文章(甚至其他文章)中看到此图片时,我个人不会’还没有在他们周围下大赌注。但是,方向显然是围绕了解组织中其他同事的适合程度以及他们所做的工作。在个人资料屏幕上的几个新标签中显示了此信息,即“通讯和分析”–在Google Analytics(分析)下有很多新内容。

通讯标签

看起来这将提供您与您的个人资料之间的通讯详细信息’重新看。我可以想象这可能是跨不同渠道的邮件的汇总,例如电子邮件,组中的对话,可能的Yammer等。时间会证明一切,但是在这里’s the visualization:

(点击图片可在新标签中查看大图)

Delve配置文件--通信选项卡

分析标签

“分析”标签的视图显示了一些不错的主意。如以下屏幕快照所示,围绕用户分析的将来可能的功能包括:

会议时间

(点击图片可在新标签中查看大图)

Delve个人资料-分析1 

热门连接

(点击图片可在新标签中查看大图)

Delve个人资料-分析2 

网络速度

(点击图片可在新标签中查看大图)

Delve个人资料-分析4 

您 might be losing touch with

(点击图片可在新标签中查看大图)

Delve个人资料-分析5

因此,Office 365中的某些功能可能会吸引人们使用–显然,某些数据/外推将在包括Office 365的所有服务中正常工作,因此只有Microsoft才能轻松构建这些东西。但它’很高兴看到这里的雄心壮志,这是我认为该服务将继续对组织变得越来越好的一个很好的指示。

SharePoint协作和团队网站的增强

This item makes me even happier than the cool stuff shown already. It was mentioned that Microsoft are investing quite in collaboration functionality, with the view that team sites should be a joy to use rather than the 平淡 functional things they are today. Initially this may take the form of relatively small but useful improvements, but in time we can expect team sites to change more radically. Examples of things that may come sooner rather than later include:

  • 改进的方式 开始 a 做cument in 您r personal (OneDrive for Business) site, then moving it to a team site for wider collaboration/publishing
  • 与Office 365组的关系的改进(稍后还将讨论)

还提到,虽然这些改进将主要在SharePoint Online中进行,但是Microsoft正在考虑将这些改进也引入本地SharePoint中的方法。他们赢了’但是不在SharePoint 2016初始版本中。

OneDrive for Business的增强功能

此处的更改包括ODFB站点的新简化用户界面,新的同步客户端,它将带来“rock solid”同步,改进的移动应用双色球推荐一注,以及围绕OneDrive使用的更好的管理控制和报告。

新的用户界面已经推出– it’使用s的速度非常快,并且可以围绕看到关键信息(预览,共享和活动信息等)使用Office 365组和不错的工具:

clip_image012

如果你没有’听说微软现在已经为OneDrive(PC和Mac)发布了一个新的同步客户端。显然,我们都希望它能够解决许多人以前遇到的同步问题。这将是一个“engine”同步个人和企业OneDrive,并带来了一些重要的改进,例如选择性同步,处理多个帐户的能力,减轻了限制(文件大小,项目限制)的麻烦等。一世’将其留给官方公告和其他帖子进行详细介绍,但这无疑是大多数使用Office 365的组织所感兴趣的。

OneDrive的其他改进包括:

  • 围绕组织的更好的报告管理工具’s use of ODFB –显然,路线图中有很多
  • 移动应用双色球推荐一注的改进–微软绝对可以预见一个这样的世界:移动员工可以使用iOS / Android / Windows应用双色球推荐一注访问其OneDrive中的常用文档

更好的Office 365组

Jeff将组描述为Office 365中的协作胶,’很明显,它们的范围将从现有功能扩展。我个人觉得很难“sell”到目前为止,“分组”作为一个概念,很容易找到次优的方面。但它’还值得记住的是’最小可行产品带来的好处!大多数人(包括我在内)都对Microsoft以前的模式消失有疑问“building”3-4年后,新功能的负载下降了,因此在增量交付的新世界中,我认为’识别显然会随着时间而发展的功能非常重要,但在早期阶段’不一定要勾选所有框。

在撰写本文时,创建Office 365组将为您提供一个OneDrive库来存储文件(以及其他工具,例如用于对话的组邮箱,日历,OneNote笔记本等)。展望未来,Jeff不仅在SharePoint方面提供了一个库,而且还提到“越来越多的正式团队站点将被解锁” –对我来说,这意味着可以使用一组更好的工具来支持一个小组。我想我们’我得拭目以待,但我个人’d希望看到其中包括以下内容:

  • 从某种自定义模板创建团队网站的能力
  • 在文档中使用自定义元数据字段/内容类型,以使可查找性​​很好地工作(例如,搜索页面上的精简双色球推荐一注)

PowerApps

PowerApps是高级用户创建有价值的业务应用双色球推荐一注的一种新方法,该应用双色球推荐一注可连接到企业数据并在PC和移动设备上运行良好。那里 ’在这里有很多要讨论的内容,本节开始变得很长,所以我将其分成单独的文章– I’会在第二天或第二天发布。

总而言之,PowerApps可用于创建与Office 365 / SharePoint,SQL Server和深入的开发人员技能领域中的数据进行对话的应用双色球推荐一注’需要在应用中创建屏幕/ UI。支持“如果那么那么那个”(IFTTT)样式的工作流程步骤-例如,“如果将项目添加到此Excel文件中,则发送电子邮件,还将项目添加到此SharePoint列表中”:

总体而言,PowerApps是事件接收器,InfoPath和工作流之间的混合体,但是还有很多额外的东西意味着它’与任何先前的技术都不是一一对应的。轻松连接到企业数据并生成专为移动设备设计的功能是关键优势。这次的另一个重大区别是解决方案的设计与I.T.–它们在Azure(Microsoft服务或您自己的服务)中运行,并且可以根据需要进行扩展。

无论如何,在我的下一篇文章中会对此进行更多介绍。

其他改进

如果不是全部’t enough for 您, there’一袋其他的东西正在准备中– and depending on 您r situation, any one of these could be big for 您 I’d say:

  • Office 365中更好的外部共享
    • 的能力share with users from *specific* other organizations (e.g. partners) –管理员可以将其他Office 365域添加到白名单
    • 对世卫组织的更多控制可以实现共享
    • 更好地报告共享的内容以及与谁共享的内容
  • Office 365混合功能的一些改进
    • 能够将自定义数据导入SharePoint Online用户配置文件
      • 这将采用新的PowerShell命令的形式- QueueImportProfileProperties – it reads from a JSON file 您 have generated (meaning the data can come from anywhere), and requires tenant admin credentials to run
      • [注:这对我来说很有趣,因为我们的许多客户都有这种需求,我们’ve以前建立了非常相似的工具来解决它]
    • 混合数据丢失预防
    • SharePoint见解
      • 在SharePoint网站上进行更好的分析(如果我理解正确的话,还可以对整个Office 365套件中的用户操作进行分析)
      • 这适用于在线和本地站点– the Insights service runs in the cloud, but can consume data fed from the on-premises side of 您r hybrid environment
      • 提到的报告类型包括“用户正在使用哪些功能?” and “如何创建和访问内容?”
    • 潜在的元数据/分类法改进–比尔提到微软 “looking 在”改善有关元数据和内容类型的混合故事。目前尚无任何消息。

概要

简而言之,’整堆东西都来了!是的,那里’始终存在差距,许多人对于Microsoft应该将精力集中在哪里有自己的看法。对我来说,仍然有物品 我的SharePoint / Office 365愿望清单 哪个唐’似乎没有得到解决,但我’我个人对我的印象非常深刻’我在看如果您开始认为Microsoft可能无法进行足够的创新来与竞争对手匹敌(包括用户倾向于解决特定问题的较小的影子IT解决方案),那么我对Office 365 / SharePoint / etc如何感到很满意。在接下来的5年中逐渐形成。尽管偶尔会出现打ic,但我们所有人对这项技术的赌注似乎仍然不错:)

Next 发布– a look 在 PowerApps

2015年11月26日,星期四

播客采访–SharePoint开发状态(2015年底)

Office开发播客尽管我之前曾几次设法躲过这个,但最终我还是设法记录了Jeremy Thake和Richard DiZerega的采访’的Office Dev播客。一世’尽管最近在伦敦见到Rich,然后在西雅图见到了杰里米,但d还是设法保持了一致–但是,随后在斯德哥尔摩召开的欧洲SharePoint会议召开了,这意味着不得不再与Jeremy呆几天,而我的借口就快用光了!当然是在开玩笑-它’和这些家伙说话总是很高兴的,坦率地说,’将向所有愿意倾听的人介绍Office 365和SharePoint开发;)

杰里米’是一位很棒的面试官,我真的很喜欢聊天。我们涵盖了从Office 365和SharePoint开发人员当前的展望到“do’s and 做n’用于在Office 365上进行开发的ts”(引用我在会议上的演讲之一),以及Office 365应用双色球推荐一注和SharePoint加载项之间的一些区别。我也讨论了为什么’我现在通常鼓励我的团队搬家 from provider-hosted SharePoint 加-ins –支持将Azure AD中的身份验证令牌与SharePoint CSOM / REST一起使用的模式,因为这有助于避免提供双色球推荐一注托管的应用双色球推荐一注的某些缺点。我们也介绍了一些更轻松的主题:)

Anyway, if 您 need something to listen to on 您r journey into work/workout/something else, 您 can get the interview 在:

Office Dev播客第72集-Chris O'Brien

2015年10月29日,星期四

我的Office 365和SharePoint的愿望清单(2015年末)

有时候’退后一步,好好考虑一下您为客户,雇主和职业所押注的技术。我最近有理由这样做,而且我认为没有理由不公开发表这些想法– so in this 发布I’d想带您浏览我列出的所有事情’d想查看Microsoft地址。在时间方面,随着我们越来越接近Office 365(下一代门户)中的新功能发布,“Planner”等等),当然还有本地SharePoint 2016版本,’进行这样的思考可能不是一个坏时刻–希望我列表中的某些项目会在不久而不是以后被选中:)

I’已将清单分解为较小/较容易完成的任务,在接下来的12个月内将很高兴看到此列表,然后列出了较大/较长期的任务。开始了:

12个月内:

  • 从中取得混合故事"basic" to "joined-up". 对于具有本地SharePoint和SharePoint Online的组织,分类,用户配置文件,用户体验(品牌,导航,自定义等)之间缺乏集成/同步是一个大问题。身份,搜索和OneDrive已很好地集成在一起非常好-但是还有很多其他领域还不是(例如 http://www.milwaukeeticketsblog.com/2015/04/improving-office-365-sharepoint-hybrid.html)
  • 采取步骤将最新和即将推出的功能与SharePoint的出色功能集成在一起。 目前,对于某些客户而言,Office 365组和下一代门户似乎已失去了应有的声誉,因为它们虽然擅长"quick and easy"他们不是那么好"planned and governed"。缺乏与分类学,搜索和Yammer的集成,造成了更多的孤岛,这意味着一些组织对这些领域的发展方向不满意。
  • 提供更好的顶级体验。 如果Microsoft,SharePoint可能会更好“did more”关于默认页面的顶层。当然,许多组织对他们的Intranet /数字工作场所主页有很高的要求– but many 做 不, yet are forced to expend effort 建造 the top-level experience. Even those with requirements would probably benefit from better out-of-the-box pieces here.
  • 通过修复内容类型,消除了对网站模板的某些需求。 这尤其适用于协作方案。内容类型中心使组织能够轻松定义和管理其内容类型而无需进行开发(特别是在Office 365中),这一点很棒,但是坦率地说,它没有用,因为这些内容类型不会应用于文档库(每个站点中没有手动步骤) 。
  • 填补空白 形式 在SharePoint中。
  • 填补空白 分析 在SharePoint中。
  • 阐明社会情况/路线图。 正如Wictor最近在 Yammer玩完了吗’s role?,有避风港’Yammer进行了大量创新,可疑的事情变得平静了。虽然我同意许多威克多’我还指出,尽管有很多麻烦的方面,Yammer在内容和代码方面(大约100名员工)还是取得了巨大的成功。当然,其中包括无用的搜索,缺少个人资料集成,无法编辑评论,收件箱怪异,对多个网络的处理不善,移动应用双色球推荐一注差强人意等。但实际上,在我看到的许多情况下,该平台仍然可以很好地运行,并且确实可以进行良好的对话和团队合作。对于Yammer来说,也许1000名以下的员工是一个不错的选择?无论如何–Yammer缺乏清晰性,需要解决社会需求,以便组织进行计划。

3年以内

  • 保持围绕文档和协作的优势,但在CMS网站/页面,移动,用户体验和某些特定工作负载方面实现了飞跃。 关于最后一点,SharePoint可以做到 这样 在大多数组织共同的工作上做得更好-运行项目,产生想法,聘用新员工等等。这些东西不需要是最好的,但是在这些领域具有与其他部分集成的功能将具有巨大的价值。
  • 加ress key end-user scenarios which still cause pain. Moving/copy and pasting items, sharing content *easily* between sites (cross-site publishing 做esn't currently cut it), seeing 所有 the sites I can contribute to, having a proper site directory (or other 发现y tools) and so on. It's a big shame that we still have these constraints in 2015.
  • 为通过简单的自定义模板创建的自助服务网站(例如具有一些调整的团队/项目网站)提供简单的选项。 OfficeDev模式和实践计划可以帮助开发人员实现这一目标,但是"从此主站点克隆"此功能应烘焙到产品中,并且进入门槛要比目前的IMHO低。
  • 解决当前体系结构附带的约束和痛点。 网站集边界就是一个很好的例子-品牌推广,许多网站设置,自定义设置以及更多挑战在全球范围内实施。
  • 消除了围绕远程代码模型的一些复杂性(例如,与Azure进行更简化的集成)。 是的,这是巨大的,我们现在有了一种企业级的方式来自定义SharePoint / SharePoint Online,同时又不影响核心SharePoint的稳定性。微软!然而,虽然它’非常适合像我(和我的老板)这样的人,他们可以把头放在Azure,Azure AD,开发模型(如Office 365应用双色球推荐一注和SharePoint加载项,身份验证选项等)周围-’d说,如果Microsoft可以稍微简化这种情况,世界可能会变得更好。 Office 365和Azure中的各个部分之间的集成方面的更多进展可能是正确的选择。

概要

以便’是我进入2015年11月的愿望清单。毫无疑问,再多花一点时间,我将添加更多项目,并且我们可以在某些方面永续发展。但是呢’在您的清单上?您是否同意我的某些观点,或者您有完全不同的迫切问题?

和唐’别忘了,各种UserVoice渠道都是将您的信息传达给Microsoft的好方法。就我个人而言’我已经把它从我的胸口拿走了’我将回到该列表并考虑应该在列表中添加什么,我建议您也为列表添加相同的方法:)

2015年9月16日,星期三

Using Azure 部署槽 to implement dev/test/production ALM for Office 365 apps and SharePoint 加-ins

这是我的第四篇文章 Office 365开发中的挑战–以及如何解决 series. 在里面past, I’ve建议使用 *多* 围绕Office 365 / SharePoint Online进行自定义开发的Office 365租赁-毕竟,通常不需要单独的开发/测试/生产环境’不要在云端消失,只是因为这些’您自己托管的物理环境。但是,这种多重租赁安排有时会带来其他挑战–在之前的文章中,我’ve讨论了开发/测试Office 365环境如何经常使用’具有诸如身份集成和SSO之类的与生产类似的方面,但是自定义应用双色球推荐一注的任何开发也带来了挑战。从根本上来说,这是因为Office 365应用双色球推荐一注和(通常)SharePoint加载项 需要在将使用该应用双色球推荐一注的每个环境中进行注册 – and this gets problematic because each registration gives a 不同 client secret and password, but 您r app typically only caters for one. 但是,在我们对问题(以及潜在的解决方案)过于深入之前,让’我在我的文章系列中考虑了这一点:

的problem –使用多个环境时使用Office 365 API

所以我’m在这里主要关注Office 365应用双色球推荐一注-换句话说,某种使用Office 365 API的应用双色球推荐一注(Web或客户端应用双色球推荐一注)。当然,还有其他类型的应用双色球推荐一注,例如提供商托管的SharePoint加载项– I’由于它们有一些不同的考虑因素,因此在本文结尾处将专门讨论这些内容。

但是Office 365应用正在变得“the new normal” for app development in Office 365, 不 least because 您 can step outside of the Office 365 APIs and use good 旧-fashioned SharePoint CSOM/REST APIs if 您 need to (but 没有 having to use SharePoint应用双色球推荐一注身份验证)。所以,在我看来’s 开始 to make less sense to create apps which will run in Office 365 as a SharePoint 加-in, rather than just creating an Office 365 app. But back to the story - to be able to read/write data to Office 365, the critical factor is that the app is registered with the Azure AD behind the Office 365 tenancy 您’re using.

如果你’不熟悉这一领域,那句话没有’对您来说有意义,请考虑每个Office 365租约背后都有一个Azure订阅。默认情况下,这仅是背景操作,并且仅包含Azure AD目录,该目录用于保存Office 365用户。但是它可以变成一个“full”通过提供信用卡进行Azure订阅– this unlocks the ability to use the 充分 set of other Azure capabilities in this subscription, 这样 as Azure web apps.

现在,如果您的应用双色球推荐一注是一个Web应用双色球推荐一注,并且您希望将其托管在Azure中,则无需将该应用双色球推荐一注本身发布到该Azure订阅中(或从中运行)。但是,必须在此Azure AD中注册该应用双色球推荐一注。一世’我们已经看到很多开发者为此付出了代价–也许是因为他们将应用双色球推荐一注发布到了他们可以访问的Azure订阅中,但实际上这与Office 365之后的Azure实例(尤其是Azure AD目录)没有关系。

所以,我们 could show this relationship like this:

所以呢’我们的应用需要在不同的地方注册的问题吗?好吧,除了随之而来的一般开销外,最大的问题是每次注册都会给 不同 客户端ID和密码。但是,Office 365应用双色球推荐一注和SharePoint加载项(由提供商托管)的设计是,客户端ID和密码存储在web.config中– Microsoft’包含在每个应用双色球推荐一注中的s身份验证处理代码在此处查找它们。

假设我们不’不想为每个环境安排一些不同的web.config文件的怪异安排,我们该怎么办?好吧,我想其他一些选择可能是web.config转换或重写Microsoft’s认证/凭证处理代码–但这些都不吸引人。

如果你’re hosting 您r app in the cloud, Azure has some nice functionality in the form of “deployment slots”在这里可以提供帮助。

Azure 部署槽 –简要介绍

部署槽是Azure Web Apps(以前称为Azure网站)的功能。它们仅在您使用时可用’re using a 标准 or Premium pricing plan. 如果你 go into the “Settings”Web应用双色球推荐一注区域中,您可以单击进入“Deployment Slots”然后从这里创建一个插槽:

您 might name this 插槽something like “Staging”. 您 can choose whether to copy any config from 您r existing “main” 插槽(which is there by default), or 不:

对于Office 365应用,这不是’重要的是’有很多配置设置值得担心。使用此过程,您可以在标准计划中最多创建5个部署插槽,在高级计划中最多创建20个部署插槽。– each 插槽effectively gives 您 an additional “instance”Web应用双色球推荐一注的代码,可以在其他URL上访问。所以对于一个网站 http://mysite.azurewebsites.net, if 您 create two slots named “test” and “staging”, 您’最终会得到一组这样的URL:

This is great Azure feature, which provides 测试/staging capabilities for 您r site in a simple way. 的re are two key aspects which provide useful support:

  • 的能力“swap”部署槽的内容– this is effectively 您r deployment mechanism to promote a version of 您r site’从测试/过渡到生产的s代码
  • Each deployment 插槽can have its own configuration, 这样 as connection strings and AppSettings 价值观

对于配置设置,可以在Azure门户中(或通过Azure API)输入值,然后 when 您 做 this these 价值观 override any specified in web.config - it’我们可以利用此功能来支持Office 365和SharePoint应用双色球推荐一注。 的re are a few other things to line-up so that 您r app can authenticate to Office 365/SharePoint, but I’以后再讲。

就使用部署槽而言,您可以使用典型的方式将网站/应用部署到特定的槽“publish to Azure” approaches –从Visual Studio发布,Web Deploy,PowerShell,FTP,从源代码管理发布等等。一旦您’在将您的应用双色球推荐一注部署到临时插槽的时候,可以将此版本的代码推送到生产环境中 交换 the 分期 and 生产 slots –使用Azure门户中的此按钮:

..或 Switch-Azure网站位置 PowerShell命令。这确实是一次交换,实际上是通过简单的DNS更新进行的–因此,如果代码更新一切正常,那么现在您的暂存槽中已有一个过时的代码库。您可以通过简单地覆盖那里的内容并随后直接发布到该广告位来解决此问题,但是’有用的是,您可以使用一种快速,强大的回滚机制来依靠’t go to plan.

您 can read Set up 分期 environments for web apps in Azure App Service to understand more about working with 部署槽 in general, but I want to now discuss them specifically for Office 365 apps and SharePoint 加-ins –与前第一。

Implementing dev/test/production for Office 365/SharePoint apps using 部署槽

现在,我们了解了部署插槽的工作原理,’我们考虑了它们可用于Office 365应用双色球推荐一注和SharePoint加载项的方法。一方面,“插槽特定的配置”强大的功能是因为我们可以使用它为不同的环境指定不同的客户端ID和密码,从而避免了单个web.config文件的问题。但有趣的是,部署插槽还为我们提供了一种拥有应用双色球推荐一注的开发/测试/生产实例的方式, 没有 having to register them with 不同 Office 365/SharePoint environments. 让’仔细考虑一下:

仅在Azure方面实施开发/测试/生产

我什么’m suggesting here is that 部署槽 are used to implement dev/test/production PURELY on the Azure side. Using an Office 365 app as an example, 所有 实例s of the app are actually registered with the 生产 仅Office 365环境。这很棒,因为它使我们避免了本系列前面列出的许多问题–诸如开发/测试环境之类的东西遭受不同的配置(例如,身份验证,Office 365计划类型等),用户数量减少,内容/数据质量较低等。现在,我们开始在生产环境中构建并测试我们的应用双色球推荐一注,尤其是针对包含生产Office 365用户的Azure AD目录。但是,我们仍在保持应用双色球推荐一注的开发/测试/生产分离,这需要我们做好发布和维护的工作。我们的应用双色球推荐一注仍然具有可靠的ALM做法,但是它们’在Azure端重新实现–这可以很好地工作,因为’s where the app’的代码和实现是。

的re are few details to line-up, since 您 need a registration of 您r app for each “instance”,即使它们全部发生在一个Office 365环境中。但它’很简单,我’很快就会讲这些。

所以,希望我’m证明这是一个不错的选择。但是在我们走得更远之前,它’还值得考虑的事情以及何时可能不合适的注意事项:

But consider if 您r app can 做 "dangerous" things in 测试ing!

因此,我们拥有应用双色球推荐一注的dev / 测试 / 生产实例,这些实例可能会或可能不会运行相同版本的代码库(例如,在升级周期中可能会有所不同)。但是所有实例都在与同一个Office 365租用进行通信–这通常是好的,因为使用了相同的Azure AD,但根据应用的用途,它也可能是不好的(或至少需要考虑)。如果您的应用双色球推荐一注可以读写Office 365数据(大概可以),那么请考虑使用它’与Office 365邮件,日历项,任务和OneDrive for Business文件相同的一组 所有 实例s of 您r app are running against –这是用户’s 生产 数据!显然,如果您的应用双色球推荐一注可以写数据,发送电子邮件或进行其他更改,则需要牢记这一点,尤其是在测试时。同样地,如果您’对SharePoint Online数据执行任何操作(例如,将数据写入列表或库),则存在相同的考虑因素。您可以在应用中实现一些特定的逻辑,但最终“仅在Azure中分离”方法可能不适用于所有情况– 您’我需要对你是否做出一些判断’d更好地以其他方式处理ALM。例如,这可能是在您拥有的每个环境中注册您的应用双色球推荐一注并将其发布到单独的Azure Web应用双色球推荐一注。

什么 it looks like – using 部署槽 for dev/test/prod in an Office 365 app

So, creating a new Deployment Slot will give 您 a new URL 这样 as //mysite-staging.azurewebsites.net,现在它将在Azure门户中列出:

But 在 this point, the 插槽is 空的 and has no website content:

因此,我们需要将我们的应用双色球推荐一注/网站内容发布到此广告位–使用上述方法之一(例如从Visual Studio发布),或者更好的方法。要是我们’重新使用Visual Studio Online进行源代码控制,它’使用自动化构建将最新的构建部署到特定的部署插槽非常简单–因此您的CI流程始终部署到测试或临时插槽,但是您 手动地 例如,选择何时将其替换为生产。一世’ll show some of this CI approach in a video in a future 发布- but in the end we just need to ensure our files get published to the 分期 插槽不知何故. HOWEVER, 您r app will NOT be 充分y working 在 this point! At first glance, 怎么样ever, 所有 looks good and 您 should see 您r app is now visible 在 the slot’s URL (N.B. I’m using the 用于ASP.NET MVC的Office 365入门项目 这里):

但是,您的应用此时将无法通过Office 365进行身份验证– it is 不 known to Azure AD. 如果你 click the “Sign in”链接并输入凭据,您’会得到一个有效地告诉您可以的错误’t sign in – most likely saying “the reply address ‘foo’与为应用双色球推荐一注配置的预期回复地址不匹配[应用双色球推荐一注ID]”, like this:

什么’这是因为正在使用web.config中用于客户端ID和密码的值。在此处找到的ClientID与Azure AD应用双色球推荐一注的注册匹配 生产 插槽– but we’在登台广告位中使用其他网址,因此“回复地址不匹配”错误。另外,那里’进入应用暂存版本的真正方法(在地址栏中输入URL除外)不是真正的方法,因为它没有’不会出现在Office 365我的应用双色球推荐一注页面或应用双色球推荐一注启动器中。因此,我们现在需要做的两件事是:

1. Manually register the 分期 实例 of the app in Azure AD – we’ll specify the 分期 插槽URL for the app’■在此处重定向URL,我们还需要授予适当的权限。

2. 配置 “slot-specific”覆盖Azure中客户端ID和密码的值 –为此,我们从Azure AD中的登台注册获取客户端ID和密码,然后使用Azure门户(或API)针对登台插槽配置这些ID,以覆盖web.config。

We’接下来将更详细地介绍这些步骤,但是在这一点上,我想创建一个简单的图标来区分“我的应用双色球推荐一注”页面中应用双色球推荐一注的暂存版本–这样的事情会做:

clip_image015
我们所有人’重新尝试做的是确保稍后可以在“我的应用双色球推荐一注”页面中分辨出哪个应用双色球推荐一注。但是让’现在更详细地进入这两个步骤:

Manually registering the 分期 实例 of the app in Azure AD

如果你’您已经开发了与Office 365 API对话的应用双色球推荐一注,那么您可能熟悉“添加连接的服务..”Visual Studio中的对话框,使您可以在Office 365中注册应用双色球推荐一注并授予权限。在这里,我们需要执行与Visual Studio相同的步骤,但直接在Azure AD中执行。

要注册登台应用双色球推荐一注,我们进入Azure AD(N.B.)的目录区域,“old”在撰写本文时,由于Azure Active Directory在预览门户中尚不可用),因此在“应用双色球推荐一注”区域中,我们单击‘Add’ button:

接下来的几张图片显示了应用双色球推荐一注注册向导中的后续步骤– here we’re supplying some details of our app, and 不ably, specifying the URL of our 分期 插槽as the sign-on URL:

一旦我们’re through the wizard, our 分期 app is registered in Azure AD:

现在,我们需要对其进行配置:

在“Configure”标签,我们上传了令人惊叹的徽标,更重要的是,获得了Azure为该应用双色球推荐一注注册生成的客户端ID和密码。对于密钥,您需要从下拉列表中选择密钥持续时间,并且当您单击时,代表密钥的字符串将可用。‘Save’。此时,请复制这些值并将其存储在安全的地方– we’下一步将需要它们:

根据应用双色球推荐一注实际执行的操作,我们还需要向Office 365中的相应数据和服务授予权限。例如,也许它需要读取或写入Exchange Online邮箱和日历,或者工作SharePoint网站和文件:

Once saved, the registration is complete and 您r app will appear in the My Apps page (if it is assigned to the current user):

However, if 您 try to sign-in 在 this point 您’ll仍然会显示登录错误:

所以,我们 now need to override the web.config 价值观 to match our 分期 app details.

加 特定于插槽 config for the Client ID and password (key):

现在,我们需要使用我们先前记下的详细信息添加特定于插槽的配置。当然,这必须在* new * Azure门户中完成,因为部署插槽仅在该位置可用J

在里面“Application settings”区域中,我们使用与web.config相同的键名,但对于 价值观 we’重新使用我们之前记下的那些:

Now save the settings, and ensure 您 see a success 不ification:

然后’s it –我们的登台应用双色球推荐一注现已在Azure中注册,并且所有内容现在都可以使用。我现在可以成功登录该应用了。

..和应用’的功能正常。例如,它可以读取我的OneDrive for Business文件夹中的文件:

因此,我们有它。现在,我们具有在Azure中运行的不同版本,但所有版本都与生产Office 365租赁挂钩。虽然我’提出了以开发/测试/生产方式使用的部署插槽(也许是最常用的用法),很明显,您可以按照自己喜欢的任何方式使用它们,也可以使用自己喜欢的任何ALM方法。沿着这些思路,其他一些Azure功能也可能会有用,例如“流量路由”。

Azure coolness - Traffic Routing for 部署槽

流量路由是一项功能,可让我将应用双色球推荐一注的一定百分比的流量定向到特定的插槽。在某些情况下这可能很有用– a soft rollout of some new functionality, A/B 测试ing and so on. Essentially I can define what proportion of traffic each 插槽should receive:

流量路由基于Cookie,因此有两种方法可以覆盖核心行为(’允许通过围绕此实现代码来通过任何特定逻辑隔离流量),但是’关于流量路由,可能要说的不多。它’s certainly a feature which could be useful in some usages though, so bear it in mind. 让’现在将我们的注意力转移到Office 365 / SharePoint开发的其他方面,以及这里的工作方式。

SharePoint 加-ins (provider-hosted) – what’处理这些吗?

许多相同的注意事项也适用于SharePoint加载项–在这里,该应用已向AppRegNew.aspx注册,然后将客户端ID /秘密添加到SharePoint环境中’s list of “known remote callers”(即AppPrincipals)。显然,如果你’重新使用开发/测试/生产SharePoint环境,则需要在每个环境中注册加载项。但是,对于此类型,还需要考虑其他几件事:

  • 向AppRegNew.aspx注册的另一种方法是使用卖方仪表板。这个*是’t* purely for app vendors 卖ing apps through the Store –在内部公司环境中使用它也是很有意义的,因为您必须回避必须在每个不同的环境中注册。 (回到本文的开头部分,’s这个选项使我说SharePoint加载项*通常*需要在不同的环境中注册– i.e. 不 always :))
  • 如果你 做 use AppRegNew.aspx to register 您r SharePoint add-in, a 不able difference compared to Office 365 apps is that 您 can provide the 相同 client ID/secret across 您r 不同 environments (因为AppRegNew.aspx表单上的字段是您可以键入的文本框)。但是,即使使用这种方法,也要考虑到’d仍然需要部署不同的应用双色球推荐一注包,因为每个应用双色球推荐一注包将具有不同的重定向URL。
  • 如果你’re hosting 您r remote components in Azure, 所有 实例s of 您r app could live in the 相同 Azure subscription, with no worries about the fact that they 所有 share the 相同 Azure Active Directory(与Office 365应用相反)。这是因为Azure AD不’用于SharePoint加载项身份验证– it 做esn’进入图片。

概要

Azure部署插槽为Office 365应用双色球推荐一注和SharePoint加载项的开发提供了一些有趣的功能。我们可以实现与同一Office 365租约交谈的应用双色球推荐一注的开发/测试/生产版本的想法可能非常有用,因为它有助于克服开头概述的非生产Office 365环境中的许多挑战。这个系列的–缺少生产数据,缺少完整的用户目录,由于身份验证方法不同而导致的SSO缺失,Yammer 企业缺失等。如上所述,您需要考虑此处概述的方法是否适合您的情况。例如,如果您的应用双色球推荐一注可以将数据写入Office 365 / SharePoint,则可能需要小心。

但是,部署槽为应用双色球推荐一注开发提供了一些有用的可能性,并且它们肯定是实现者中的有用工具’s toolbox.

2015年8月7日,星期五

Enabling Yammer 企业 with SSO in dev/test Office 365 environments

这是3rd 我的文章 Office 365开发中的挑战–以及如何解决 系列。今天我们’ll focus on Yammer – for my team, it’在Yammer周围进行少量开发变得越来越普遍,因此在开发/测试环境中进行正确的设置开始变得重要。这可以是非编码方法,例如使用“Yammer Embed”方法,例如显示“Development”小组网站主页上的Yammer中进行分组,或使用Yammer在Intranet页面上发表评论。但是,我们还发现自己使用Yammer API实现了简单的操作,例如,在授予用户对团队网站的访问权限时,将用户自动添加到Yammer组。对于这些情况,您确实希望测试环境中的行为与生产中的行为完全相同。但是在我们进一步之前,让’将此放在整个系列内容的上下文中:

Why Yammer 企业 is important in dev/test environments

让’显然,在没有Yammer 企业的情况下,有可能为Yammer开发–我上面提到的两种情况确实可以通过Yammer的免费版本完成。但它’说你也很公平’在Office 365 / Yammer之间将围绕用户身份和单点登录(SSO)进行一些折衷。如果您有多个Office 365环境(例如开发/测试/生产),则您’最有可能的情况是,只有产品才具有最终用户会看到的真实用户体验。这可能对您来说是可以接受的,但同样会给测试带来挑战(“OK, but just 想像 您 做n’不必在这里登录!”)
Specifically, the things 您’ll miss 没有 Yammer 企业 are:
  • 用户必须使用其电子邮件地址在Yammer网络中手动注册(或被邀请)–这一步将创建他们的Yammer个人资料
  • 单点登录不起作用–页面上的任何Yammer功能(例如,供稿或“Like”按钮),将显示一个登录Yammer的链接,导航到Yammer主站点也将需要登录,而不仅仅是自动将您引导通过
  • All of the Yammer features which come with Yammer 企业, 这样 as the reporting and administration tools
On a related 不e, developers using Yammer嵌入 will 不ice the “use_sso”嵌入代码中JavaScript对象上的标志(请参见 //developer.yammer.com/docs/single-sign-on). From memory, even with Yammer 企业 enabled this has to be set to “true”避免2中列出的行为nd 以上的要点。
还有’还可能值得一提的是Yammer的SSO有不同的风格。我在这’m referring to “带有Yammer的Office 365 SSO”,但请注意,始终可以在Office 365出现之前实施Yammer SSO形式–对于Yammer和您的其他公司系统,通常使用基于SAML的IdP(例如ADFS)。取决于您的组织’的情况,即使您使用Office 365,您实际上可能会发现您实际上只能使用“plain”Yammer SSO,而不是Office 365 SSO(例如,您的用户没有电子邮件地址或多个Yammer网络)。看到 //support.office.com/en-us/article/Office-365-sign-in-for-Yammer-b1745e3c-d4d7-4e20-a155-ebf85106b998 有关更多信息。

有关许可和其他先决条件的说明

所以,我们’d like to use Yammer 企业 even in dev/test environments if possible. However, this 做es require licenses for any user who will access Yammer since we’超越了免费版本。考虑以下:
· 如果你r dev/test Office 365 tenant is on an 企业 plan (e.g. E1, E3) 您r users will automatically have a Yammer license –这些不需要在Office 365租户管理员屏幕中分配
· 如果你’re on some other kind of plan (e.g. a SharePoint-only plan 这样 as SharePoint P2), then 您 can “additively”支付个人Yammer许可证作为附加费用– these 需要分配给单个用户
In addition to licensing, another key pre-req is that Yammer 企业 can only be activated on an Office 365 tenant which is integrated with a custom 做main - in other words, 您r user accounts will be “chris@mycompany.com” rather than “chris@mycompany.onmicrosoft.com”. This would either be 做ne in the normal way during the initial set-up process, or for dev and 测试 environments 您 could use the approach I discuss in 使用子域与Office 365实施AD集成(用于开发/测试)
But assuming licensing and 做main integration are in place, 您’re good to go with Yammer 企业.

HOW-TO: configure Yammer 企业 for an Office 365 environment

转到Office 365租户管理仪表板,然后单击“Included Services”,然后在页面右侧,单击“Yes, activate Yammer 企业 for my network”:
clip_image002
您’ll then be asked which 做main 您 want to use for Yammer – assuming 您 only have one verified/integrated 做main, 您’re simply confirming 您 want to proceed:
clip_image004
此时,Yammer网络设置过程开始:
clip_image005
clip_image006
完成后,您会看到以上消息,您应该可以点击“log in to Yammer” link and sign-in. 在next screen, some home 真实m 发现y stuff kicks in and detects that 您 can be signed-in on 您r current identity 没有 providing a password:
clip_image007
From there 您 can complete the sign-up wizard –添加任何Yammer同事,加入/开始组以及添加个人资料照片:
clip_image008
和瞧– 您 now have Yammer 企业!
clip_image010
如果你没有’t 做ne already, 您 should switch the Office 365 tenancy to use Yammer for social:
clip_image012
Once 所有 these steps are complete, 您’ll know the Yammer network is a Yammer 企业 because 您 should see the additional administration tools:
clip_image013

概要

以便’s如何在Office 365租约中启用Yammer 企业用作开发或测试环境(或为此生产) – the process is the 相同). 如果你 go through this process, 您r dev/test Office 365 environments should behave just like 您r 生产 environment. This can often be an important point for 测试ing, especially around mobile devices and other non-domain joined devices, and especially where Yammer嵌入 or any custom Yammer functionality has been implemented.
本系列将继续讨论用于改进Office 365开发的选项和技术。其他职位:

2015年7月15日,星期三

SharePoint加载项(应用双色球推荐一注)开发中的调试错误

If I was to summarize this 发布in one sentence, I’d say “if 您r SharePoint app/add-in is giving a generic error 这样 as ‘An error occurred while processing 您r request’, then 您’可能是错误的外接双色球推荐一注注册/身份验证!”。这适用于提供双色球推荐一注托管的SharePoint加载项,而不适用于SharePoint托管的加载项,并且’不适用于使用Office 365 API替代SharePoint加载项模型的应用双色球推荐一注。但是对于开发/部署SharePoint加载项的任何人来说, 真实ly SharePoint / Office 365开发人员的常见经验– 大家 在某个时候搞定了这个问题:)有很多论坛帖子,可能还有一些与此相关的文章,但是我似乎总是陷入这个陷阱(通常是有错字之类的东西),然后花1-2个小时调试和搜索互联网直到我记得具体的问题是什么。所以,我只是想从我的身上转移一下 Office 365开发中的挑战–以及解决这些问题的方法 关于这个的系列部分是为了让我下次遇到问题时有个快速参考,因为我知道我肯定会:)

问题症状

当你 click on 您r add-in, 您 are taken to the remote website (e.g. on 本地主机, or in Azure, IIS, or wherever 您 published it to) but instead of seeing the default page 您 simply see a white page with a simple message:
clip_image001
发生这种情况是由于大多数SharePoint加载项中都存在此样板代码–请参阅“ CanNotRedirect”案例:

Uri redirectUrl;

switch (SharePointContextProvider.CheckRedirectionStatus(Context, out redirectUrl)) 
{ 
    case RedirectionStatus.Ok: 
    return;

    case RedirectionStatus.ShouldRedirect: 
        Response.Redirect(redirectUrl.AbsoluteUri, endResponse: 真正); 
    break;

    case RedirectionStatus.CanNotRedirect: 
        Response.Write("An error occurred while processing 您r request."); 
        Response.End(); 
    break; 
}


如果你 perform any debugging and step through the code, 您’ll probably end up in the TokenHelper class, 看着 this method:

public static string GetContextTokenFromRequest(HttpRequestBase request) 
{ 
    string[] paramNames = { "AppContext", "AppContextToken", "AccessToken", "SPAppToken" }; 
    foreach (string paramName in paramNames) 
    { 
        if (!string.IsNullOrEmpty(request.Form[paramName])) 
        { 
            return request.Form[paramName]; 
        } 
        if (!string.IsNullOrEmpty(request.QueryString[paramName])) 
        { 
            return request.QueryString[paramName]; 
        } 
    }

    return null; 
}

在很多情况下,’会发现此方法返回null–实际上,在URL或帖子正文中找不到任何指定表单参数的值。我们’已成功传递了许多早期代码,并且有效的上下文令牌已从SharePoint / Office 365传递到加载项中,但是我们’在这一点上失败了。

深层发掘

当您单击加载项时(例如,在“ SharePoint网站内容”页面中),您将被带到AppRedirect.aspx–此页面最终会重定向到您应在应用双色球推荐一注注册中指定的重定向URL。这是POST形式,在请求的主体中是远程代码所需的令牌。或者至少应该如此。在没有事情的情况下’t working, 您’会注意到未传递令牌(例如,在Fiddler中):
加-in redirect - Fiddler 1
加-in redirect - Fiddler 2
We can see two things about the body of the form 发布from the image above:
  • 的SPAppToken parameter is 空的
  • 的SPRedirectMessage parameter gives us a clue about my specific problem, with a value of “EndpointAuthorityDoesNotMatch
要明确的是, EndpointAuthorityDoesNotMatch 消息只是此问题的一种味道– 您 might see something else here depending on precisely 怎么样 您’ve messed up 您r app registration/authentication setup :) For example, 您 might have the add-in registration 所有 correct, but 您’重新尝试在HTTP而不是HTTPS上运行应用双色球推荐一注– in that case, 您’ll see:
  • 空的SPAppToken
  • SPErrorInfo参数包含类似“请求的操作需要HTTPS(SSL)通道。确保目标端点地址支持SSL,然后重试。”
该邮件将被编码,因此看起来将更像这样(对于将其粘贴到互联网搜索中的任何人):
SPErrorInfo =请求的操作+需要+一个HTTPS +%28SSL%29 +通道。++确保+目标+端点+地址+再次支持SSL +和+ try +。
clip_image002
如果你’在重新开发高信任度的外接双色球推荐一注(用于本地SharePoint)时,问题的另一种味道是您没有’t列出了身份验证要求–特别是通过证书方面的令牌签名。看到 打包和发布SharePoint 2013的高信任度应用双色球推荐一注 for more info if this is 您r scenario.
就我而言 EndpointAuthorityDoesNotMatch 告诉我,远程应用双色球推荐一注的URL与该客户端ID的应用双色球推荐一注注册中期望的不匹配。我可以使用/_layouts/15/AppInv.aspx页面查找在/_layouts/15/AppRegNew.aspx注册应用双色球推荐一注时指定的详细信息。重要提示:如果最后一句话没有’对你和/或你没有多大意义’重新开始于外接双色球推荐一注开发,那么您的错误可能是您刚刚没有’根本没有注册加载项!下一节可能会有所帮助:

背景-开发外接双色球推荐一注时要了解/记住的关键事项

加-in registration

加载项需要向SharePoint / Office 365注册,并要求一组必需的权限(安装加载项的人必须同意)–否则,您实际上只能在SharePoint之外尝试读取/写入数据的地方有一些随机代码,因此安全机制将启动,并且您的代码将被阻止。可以通过针对广泛分布的加载项(即使只是在您自己的环境中)的卖方仪表板来完成此操作,也可以通过将AppRegNew.aspx页用于其他类型来完成此操作。如果您需要一些背景知识,建议您阅读以下内容- 为SharePoint 2013注册应用双色球推荐一注的准则
“Development mode” vs. “打包用于部署模式”
在开发外接双色球推荐一注时,Visual Studio确实会尽力帮助您。当我按F5键启动并调试加载项时,已经做好了很多事情,因此我可以快速运行并查看我的代码-我认为这是“development mode”. 让’讨论这里发生的事情,以及以后打包部署到另一个环境时需要考虑的问题。
发展历程 mode:
在按F5键时,加载项将打包并部署到指定的SharePoint网站-该网站可以是本地的,也可以在SharePoint Online中,并且删除那里的所有先前安装。此外,外接双色球推荐一注会自动在此SharePoint环境中注册。假定确实可以在指定的URL上浏览加载项的网站(即远程ASP.NET站点),则F5进程将打开一个浏览器窗口,在该窗口中正在安装/信任该应用双色球推荐一注,然后您可以单击图标,然后进入应用。其他注意事项:
  • 的URL for the remote ASP.NET website is specified in the properties 用于加载项Web项目 – by default, a “localhost” URL 这样 as http:// _ localhost:44311 / is used against 您r local IIS Express 实例. It’s possible to change this in the project properties, for example to a named virtual directory URL for use with a 充分 IIS 实例.
  • 如果使用IIS Express,则应考虑是否可以将localhost与计算机上的HTTPS一起使用。我脑子里有可能在某处指定它不应该用于远程网站SSL– but frankly I can’现在,请记住是否为真或如何找到它’s possible now, so that could be nonsense :) I always run on the 充分 local IIS 实例 and have SSL running on 本地主机, and that works for me.
  • 身份验证也需要考虑。通常你’ll need to ensure “Windows验证”可以在Web项目上启用,以便可以标识当前用户,并可以进行向SharePoint的身份验证。但是,如果您’重新开发将向Azure AD进行身份验证的Office 365加载项,这是’t the case.
  • In 发展模式, 您r app manifest is expected to have a ClientID value of “*”。 Visual Studio将在打包/调试时将其替换为正确的值。
打包为部署模式:
当你’准备考虑将加载项部署到其他人可以看到的位置(例如,Azure,某些IIS服务器或其他地方)’(在本地开发箱中),则需要在部署之前更改文件中的几项内容。有关部署过程的端到端演练(使用Azure Web Apps作为托管平台),请参见 将SP2013提供双色球推荐一注托管的应用双色球推荐一注/远程事件接收器部署到Azure网站(用于Office 365应用双色球推荐一注) 发布–这是前一段时间写的,但我’自从考虑到Azure和Visual Studio中的更改以来,已经对其进行了更新。但是,这是从中进行的关键更改“development mode”:
  • 处理加载项注册–转到将在其中使用外接双色球推荐一注的SharePoint环境中的AppRegNew.aspx,并注册外接双色球推荐一注(提醒–要么查看我的最后一个链接,要么 为SharePoint 2013注册应用双色球推荐一注的准则 if 您’re 不 clear on this step!) For the app/add-in ID, either generate a new GUID on the page or use the existing ClientId value in 您r project files –关键是它们匹配,’s 所有.
    • 记下AppRegNew.aspx页上使用/生成的ClientId和ClientSecret– 您’ll need these!
  • 确保web.config的AppSettings部分包含外接双色球推荐一注注册中的ClientId和ClientSecret(上一步)–如果需要,覆盖现有值。 Visual Studio工具(TokenHelper.cs)烘焙到每个外接双色球推荐一注中的身份验证代码将从此处读取值。
  • (可选)找到您的appmanifest.xml文件并替换“*”在ClientId值中,并带有注册中的附加ID–有效地将其中的值硬编码。此步骤在技术上是可选的,因为在Visual Studio中打包应用双色球推荐一注的过程(下一步)实际上将替换“*”使用您始终指定的GUID值,但是不要依赖它,而是在appmanifest.xml中显式指定GUID是有意义的-例如,如果您’重新分发VS项目文件,或者也许是aren’期望做更多的本地开发/测试。否则,我们’下一步将处理。
  • (可选)更换“~remoteAppUrl”appmanifest.xml中的值也– it’与上一点完全相同的交易/考虑。
  • 使用Visual Studio发布外接双色球推荐一注的两个元素(外接双色球推荐一注远程网站和外接双色球推荐一注包)“Publish..”机制。右键单击该外接双色球推荐一注项目,然后单击“Publish..”,您应该会看到一个对话框,可帮助您发布两个VS项目的输出:
    VS SP加载项发布对话框1
    您’我需要同时按下这两个按钮:)第一个按钮将帮助您发布Web项目–如果要轻松发布到Azure,请确保已安装Azure SDK。这将使您能够“discover”并在您的订阅中发布到Azure Web Apps(网站),而不必单独下载用于连接的发布配置文件。

    第二个按钮将打包应用双色球推荐一注– 您’系统会要求您提供一些关键详细信息,这些详细信息将放入包装中:

    VS加载项发布对话框2

    在打包过程中,将在生成的.app文件中将几件事烘焙到appmanifest.xml中(这就是为什么前面的某些步骤是可选的):
    • 的〜remoteAppUrl token will be replaced with the remote website URL 您 specify
    • 的“*”ClientId值中的将会替换为上面Client ID文本框中的值

      NOTE - 您 won’t see any changes in 您r source appmanifest.xml file. It’s only if 您 crack open the add-in, by renaming from .app to .zip, and examining the files inside will 您 see where this has happened.
  • 获取外接双色球推荐一注包并将其部署到您的环境的SharePoint外接双色球推荐一注目录中(在Office 365或本地SharePoint中)。将.app文件拖到目录中,然后将所有其他详细信息(例如,加载项说明,屏幕截图等)添加到该文件的列表项中。
的add-in is now available to be installed to SharePoint sites.

回到我的问题

无论如何,AppInv.aspx允许我输入客户端ID /应用双色球推荐一注ID(标识加载项/一些远程代码),并查看注册的详细信息:
AppInv.aspx
当我点击“Lookup”按钮,其他文本框将使用注册详细信息填充,如上所示。就我而言,我现在可以看到自己犯的错误– it’s the “www.”在应用双色球推荐一注域/ URL中。当我考虑我的远程站点实际上正在运行的URL时,它’s actually just http:// _ cob- [foo] .azurewebsites.net 没有“www.” – as 您 can see if 您 look back 在 the first image in this article.

因此,我的解决方案是使用正确的URL重新注册加载项。
It’s 不 possible to modify an existing add-in registration, so 您 need to 做 a new registration with a new App ID (and update the Client ID value in 您r app manifest etc.) 您 can tidy up the 旧 app registration by going to AppPrincipals.aspx and deleting the original app principal there.

概要

开发SharePoint加载项存在一些常见的陷阱,即使具有一定的经验水平也是如此 ’容易陷入其中之一!要寻找的一些关键事项包括加载项注册中的错误,以确保您知道两者之间的区别“development mode” and “包装生产方式”,以及远程Web应用双色球推荐一注上对HTTPS的需求。如果一切正常,则您的加载项应该工作正常。
史蒂夫·佩斯卡(Steve Peschka)在以下方面对此领域提供了更多好的提示 //samlman.wordpress.com/2015/03/01/more-troubleshooting-tips-for-high-trust-apps-on-sharepoint-2013/

在里面next post, I’我将继续在 Office 365开发中的挑战–以及如何解决.