小编Poo*_*eld的帖子

在 Azure 门户中，可以根据对象 ID 查找 Azure AD 对象，如下所示：

是否可以使用 Azure CLI 通过对象 ID 检索 Azure AD 对象？

为了使用Azure CLI获取与对象ID相关的对象，看来我需要提前知道相关资源是否是用户、组、设备、应用程序注册等，以便获取详细信息。例如，如果我知道对象 ID 是用户，我可以使用az ad user show --id. 如果我只有对象 ID，我不知道对象的“类型”，但 Portal 可以以某种方式弄清楚这一点！

虽然我更喜欢 Azure CLI 解决方案，但 Azure PowerShell 解决方案总比没有好。我问这个问题是因为我试图使用 生成密钥保管库中的访问策略列表az keyvault list，但该 CLI 命令中的访问策略列表仅显示每个策略的对象 ID...我无法确定对象是否是用户、组等。

使用 Hassan Habib 的Supercharge ASP.NET Core API 和 OData博客文章中的示例代码，我能够使用 OData 查询获取记录计数$count=true：

需要配置什么才能将响应对象包装在 an 中，OData context以便显示该@odata.count属性？

在我自己的 ASP.NET Core Web API 项目中，我无法使用简单的$count参数，我也不知道为什么。

使用 Hassan 的示例代码，响应 JSON 被包装在 an 中OData context，有效负载（一个IEnumerable<Student>对象）位于valueJSON 响应的属性中。在我的项目中，OData context包装器不存在；我的代码从不返回OData context，它只返回类型的有效负载对象IEnumerable<T>：

我还注意到Content-Type响应头application/json; odata.metadata=minimal; odata.streaming=true; charset=utf-8中的 位于示例项目中，而它只是application/json; charset=utf-8在我的项目中。我在任何一个项目中都没有看到任何控制它的设置，所以我假设Microsoft.AspNetCore.OdataNuGet 包在正确配置时神奇地改变了响应。

我的项目也使用 .NET Core 2.2（从 2.1 升级），所有与 Hassan 示例项目相同版本的 NuGet …

[Required]当 JSON 请求没有为枚举属性提供正确的值时，是否可以返回属性错误消息？

例如，我有一个包含AddressType枚举类型属性的 POST 消息模型：

public class AddressPostViewModel
{
    [JsonProperty("addressType")]
    [Required(ErrorMessage = "Address type is required.")]
    public AddressType AddressType { get; set; }
}

该AddressType枚举接受两个值：

[JsonConverter(typeof(StringEnumConverter))]
public enum AddressType
{
    [EnumMember(Value = "Dropship")]
    Dropship,
    [EnumMember(Value = "Shipping")]
    Shipping
}

我注意到（或者实际上我的 QA 团队注意到）如果请求消息 JSON 包含空字符串或 null AddressType，则错误消息不是预期的Address type is required.消息。相反，错误消息是一个有点不友好的解析错误。

例如，如果请求 JSON 如下所示：

{  "addressType": "" }

然后验证框架自动生成的错误如下所示：

{
    "message": "Validation Failed",
    "errors": [
        {
            "property": "addressType",
            "message": "Error converting value \"\" …

我试图通过使用它的 Rest API在Azure DevOps wiki 中创建一个新页面来自动在 Azure DevOps 发布管道中创建发行说明。

我遇到的问题是我使用 PowerShell 脚本任务发布到 Rest API，我想避免使用个人访问令牌 (PAT) 并改用 OAuth。PAT 到期，我不希望所有版本在 PAT 到期时突然失败。通过在构建代理的上下文中使用 OAuth 运行 PowerShell 脚本，我可以避免此过期问题。我在代理作业中选中了“允许脚本访问 OAuth 令牌”以获取 PowerShell 脚本任务所在的版本。

为简单起见，我正在运行以下内联PowerShell 脚本来测试使用 OAuth ( "Bearer $env:SYSTEM_ACCESSTOKEN")创建新的 wiki 页面：

$uri = "https://dev.azure.com/{organization}/{project}/_apis/wiki/wikis/{wikiIdentifier}/pages?api-version=5.0&path=/Release%20Notes/Customers%20API/Release-299%20[Build:%2020191010.1]";

try {
    $response = Invoke-RestMethod `
    -Method PUT $uri `
    -Headers @{Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"} `
    -ContentType "application/json" `
    -Body $json
} catch {
    Write-Host "Message: " $_.Exception.Message;
    Write-Host "StatusCode: " $_.Exception.Response.StatusCode.value__ …

TL;DR - 作为构建过程的一部分，是否有用于格式化代码的 Azure DevOps 管道任务？我一直没能找到一个，但确实发现它很有用。

我的团队使用免费的CodeMaid Visual Studio 扩展来“美化”（格式化）C# 代码。虽然该扩展运行良好，但依赖开发人员在 Visual Studio 中格式化自己的代码存在一些限制：

• 开发人员经常忘记运行该工具。
• 在代码运行时启用“保存时自动运行文件清理”可能会令人沮丧，因为它会重新组织代码，这可能会打乱人们的思路。
• 开发人员可以根据自己的喜好更改格式设置，而不是遵守团队的格式标准，这可能会导致代码合并问题和格式战争。

我认为更好的解决方案是在 Azure DevOps 中设置一个管道任务，在构建过程中运行 Code Maid 等工具。这将确保没有代码以丑陋、未格式化的状态进入源代码管理，并确保所有代码都格式化为构建过程中启用的任何标准。

创建Azure APIM 操作后是否可以更改operation name（也称为）？operationId