小编Tod*_*ier的帖子

我正在编写PowerShell脚本以在IIS 7.5中执行某些管理功能.

import-module WebAdministration

在某些情况下,我知道我想要使用的Web应用程序的名称,但不知道它所在的网站.获取应用程序很简单:

$app = get-webapplication -name 'MyApp'

但我无法弄清楚如何获得给定应用程序的网站的名称.它似乎不是webapplication对象的属性.我想出的最好的尝试是通过测试路径获取它:

get-website | where {test-path "iis:\sites\$_.name\MyApp"}

由于某些原因,空的.有关如何去做的任何想法？提前致谢.

I work on a few .NET web apps that use Redis heavily for caching along with ServiceStack's Redis client. In all cases I've got Redis running on the same machine. I've used both BasicRedisClientManager and PooledRedisClientManager (always implemented as singletons) and have had some issues with both approaches.

With BasicRedisClientManager, things would work fine for a while, but eventually Redis would start refusing connections. Using netstat we discovered that thousands of TCP connections to the default Redis port were …

这个问题的后续行动.我有一个包含许多异步方法的库,可以进行精简包装HttpClient.实际上他们只是做了一些设置并直接Task返回从HttpClient通话中返回的内容:

public Task DoThingAsyc() {
    // do some setup
    return httpClient.DoThingAsync();
}

我在考虑是否要添加ConfigureAwait(false)这些调用.流行的智慧似乎是"是的,总是在图书馆那样做".但是在这种情况下,它会引入一些(可能是可忽略的)开销,因为ConfigureAwait返回一个ConfiguredTaskAwaitable需要被包回到a Task中以便不改变方法签名.当然不难编码:

public async Task DoThingAsyc() {
    // do some setup
    return await httpClient.DoThingAsync().ConfigureAwait(false);
}

我的问题是,效率优势是否ConfigureAwait(false)会超过这种情况下引入的额外开销？以上哪个例子被认为是更好的做法？

我正在努力将我们的开发团队迁移到Subversion并改进我们的存储库结构和流程.我们基本上采用标准的trunk/branches/tags设置.我原本打算使用发布分支策略(branches/1.0,branches/2.0等),但现在我倾向于代码推广模型(测试和生产分支).对于我们团队的工作方式来说,它会更好一些,更直观,但是发布会不那么简单:我们有效地需要测试分支成为生产分支.(生产分支始终可用于维护版本,但在一个版本的部署和下一个版本的测试就绪之间不需要存在测试分支.)

使用代码促销的任何人都可以推荐实现从测试到生产推广分支的最佳方法吗？我认为这些是我的选择,但不知道他们是否有重大利弊:

一个.将测试分支完全合并到生产分支中,删除测试分支
b.删除生产分支,将测试复制到生产,删除测试分支
c.删除生产分支,将测试分支重命名为生产

谢谢你的建议!

我正在努力升级我们在内部使用Quartz.net的作业调度系统.看看Quartz的最新版本的源代码,我注意到它仍然使用自己的线程池实现,而不是从.NET 4.0开始随附的大大改进的线程池(或来自System.Threading.Tasks的任何东西).

我很想知道是否有人成功实现了一个作业调度系统,该系统使用Quartz.net进行调度功能,TPL用于线程池.是否相对容易将Quartz的线程池替换为TPL的线程池？Quartz甚至在任务世界中仍然相关吗？另外,正如我对.NET 4.x线程池(核心感知,本地队列,改进的锁定等)的巨大改进一样出售,Quartz的线程池足以满足典型的粗粒度后台作业而且不值得迫使TPL融入其中的努力？

提前感谢您对使用(或不使用)这两个工具的任何见解.

在Json.NET文档中的性能提示的帮助下,我整理了一个从远程资源下载/反序列化JSON的方法:

public async Task<T> GetJsonAsync<T>(string url) 
{
  using (var stream = await new HttpClient().GetStreamAsync(url))
  {
    using (var sr = new StreamReader(stream))
    {
      using (var jr = new JsonTextReader(sr))
      {
        return new JsonSerializer().Deserialize<T>(jr);
      }
    }
  }
}

我想要一个返回a的非泛型版本dynamic.用work调用上面的方法GetJsonAsync<dynamic>(url),直到你尝试访问结果的动态属性,此时我得到:

'Newtonsoft.Json.Linq.JObject' does not contain a definition for '[MyProperty]'

我已经看到如何从字符串反序列化为动态,但没有看到直接从流中执行它的工作示例,这将是更好的,因为它更有内存效率.这可能吗？

我正在使用 Elasticsearch.NET 在 .NET 环境中使用 Elasticsearch 进行一些自定义错误处理/日志记录。给定一个IResponse对象，我试图找到最佳策略来提取简短、简洁且有用的“根本原因”消息。我最初是这样做的，当我们遇到索引错误时，它非常有效：

shortMsg = response.ServerError?.Error?.RootCause?.FirstOrDefault()?.Reason;

但我最近遇到了一个查询时错误，上面给了我这个：

"failed to create query: { ... }"

（省略了详细信息，但它有效地转储了整个查询。）

由于这不是特别有用，因此我花了一点时间浏览response以查看还有什么可用的。response.ServerError.Error.Reason，例如，返回"all shards failed"- 也不是特别有用。response.DebugInformation比我想要的这个特定目的要大得多，但我确实在大海捞针中找到了我正在寻找的目标：

"Can't parse boolean value [True], expected [true] or [false]"

这是完美的，为了避免解析它，DebugInfomation我还设法在这里找到它：

"failed to create query: { ... }"

所以现在我已经制定了这个策略来获得我的shortMsg：

"Can't parse boolean value [True], expected [true] or [false]"

我对此的担忧是，假设如果第一个路径上存在某些东西，它总是比第二个路径“更好”，这可能是天真的。更好地理解响应结构本身可能是制定最佳策略的关键。

有什么改进的建议吗？

使用C# - ASP.NET MVC 4,我可以定义一个异步控制器动作,如:

public async Task<ActionResult> IndexWorks()
{
    var data = await DownloadAsync("http://stackoverflow.com");
    return Content(data);
}

有没有办法做类似的事情,使用F#？

我知道我可以使用这种AsyncManager方法.我也知道@Tomas Petricek做得很整洁AsyncActionBuilder,但与C#方法相比,感觉就像很多样板.

Azure的WebJob SDK使用在定义的存储连接字符串AzureWebJobsStorage,并AzureWebJobsDashboard为它的记录和仪表板应用程序设置.

WebJob SDK在以下位置创建以下blob容器AzureWebJobsStorage:

• azure-webjobs-hosts

WebJob SDK在其中创建以下blob容器 AzureWebJobsDashboard

• azure-jobs-host-output
• azure-webjobs-hosts

当WebJob运行时,会在上面的blob容器中创建许多blob.如果没有清理机制,容器可能膨胀或饱和.

上面blob容器的清理机制是什么？

更新

以下答案是一种解决方法.此时,没有内置机制来清理WebJobs日志.作业长期运行时,日志可能会堆积很大.开发人员必须自己创建清理机制.Azure Functions是实现此类清理过程的好方法.以下答案中提供了一个示例.

考虑以下代码:

if (request.Headers.Contains(headerName))
    ...

其中request是System.Net.Http.HttpRequestMessage的实例.headerName相当随意; 我们假设它来自用户输入.如果它的值恰好是"Content-Type",则抛出异常:

System.InvalidOperationException:未使用的标头名称.确保请求标头与HttpRequestMessage一起使用,响应标头与HttpResponseMessage一起使用,内容标头与HttpContent对象一起使用.

我究竟如何"确定"这一点？该Headers集合在内部知道允许哪些标题名称,并且此列表request.Headers与其不同request.Content.Headers.看来我有2个选项来验证任意字符串:

1. 根据BCL文档或源代码,保持自己的"白名单"进行验证.
2. 使用try/catch逻辑.

这些方法都不是理想的.有没有办法利用已经包含的知识System.Net.Http来执行此验证？