小编Hok*_*ike的帖子

Docker noob在这里......

如何正确运行由Visual Studio 2017在命令行生成的Asp.Net CORE应用程序的docker镜像？

docker run -it -d -p 80:32769 myappimage

似乎没有正常工作(图像运行,但我无法浏览到我的应用程序)

注意:我只是使用默认模板在Studio中创建了一个示例ASP.Net Core Web App,并添加了Docker支持(通过单击"添加Docker支持"复选框).当您执行此操作时,Studio会添加dockerfile和一些docker-compose文件.

当Visual Studio"运行"图像时(通过按F5) - 我可以成功浏览到我的应用程序(通过" http:// localhost:32789 "或类似的主机端口.容器内的应用程序位于端口80上).但我无法弄清楚在命令行自己运行它的命令.

Studio添加到项目中的标准Dockerfile是......

FROM microsoft/aspnetcore:1.1
ARG source
WORKDIR /app
EXPOSE 80
COPY ${source:-obj/Docker/publish} .
ENTRYPOINT ["dotnet", "WebApplication2.dll"]

我们有几个使用Windows身份验证的Web应用程序在IIS6上运行良好.将它们部署到IIS7后,Windows身份验证不再有效(我们得到401.2错误)除非我们将Web应用程序设置为使用"经典管道"

我意识到这里和这里提到的Forms auth和Windows Auth不是同时支持的- 但这不是我的问题 - 我没有启用表单身份验证.我只启用了Windows身份验证 - 但我总是得到401.2

有没有人碰到这个？我还需要做些什么吗？

谢谢!-麦克风

我有一个简单的单元测试，我使用相同的参数执行相同的 NHibernate 命名查询 2 次（每次不同的会话）。这是一个简单的 int 参数，由于我的查询是一个命名查询，我假设这两个调用是相同的，并且结果应该被缓存。

事实上，我可以在日志中看到结果正在被缓存，但使用不同的键。因此，我的第二次查询结果在缓存中从未找到。

这是我的日志中的一个片段（请注意密钥有何不同）：

（第一个查询）

DEBUG NHibernate.Caches.SysCache2.SysCacheRegion [(null)] <(null)> - 添加新数据：key= [snipped]...参数：['809']; 命名参数：{}@ 743460424 & value=System.Collections.Generic.List`1[System.Object]

（第二次查询）

DEBUG NHibernate.Caches.SysCache2.SysCacheRegion [(null)] <(null)> - 添加新数据：key=[snipped]...参数：['809']; 命名参数：{}@ 704749285 & value=System.Collections.Generic.List`1[System.Object]

我已将 NHibernate 设置为使用查询缓存。我将这些查询设置为可缓存=true。不知道还能去哪里看。有人有什么建议吗？

谢谢
-迈克

在我们的Web API 2应用程序中,我们像这样全局配置JSON格式:

var jsonformatter = GlobalConfiguration.Configuration.Formatters.JsonFormatter;      
jsonformatter.SerializerSettings.ContractResolver = new CamelCasePropertyNamesContractResolver();

这很好用 - JSON是camelcase ..,直到我们改变我们的控制器方法以返回一个HttpReponseMessage(而不是直接响应模型类型),如下所示:

Request.CreateResponse(HttpStatusCode.OK, response);

这一个变化似乎导致MVC不使用JSON格式化程序.我们的JSON不再是CaemlCase.

这是预期/设计的行为还是我没有正确指定格式化程序？

谢谢,-Mike

我的组织正在从 SVN 过渡到 Git（托管在 GitHub 上），我们基本上采用了 git-flow 分支模型。

我们一直在使用拉取请求在分支之间进行合并。我们使用 GitHub Web 界面来处理合并并关闭请求。

拉取请求与 --no-ff 合并。因此，合并提交将发生在目标分支中。

所以......我们经常从开发合并到主控- 所以合并后发生的情况是开发分支将既落后（由于合并提交不在主控中）又领先（由于开发中正在完成新工作） 。

经过多次迭代，我们最终得到“develop 分支落后 23 次提交，领先 master 7 次提交”——这看起来很荒谬。我们不应该担心这个吗？我们应该手动合并而不是通过 GitHuib Web 界面吗？

所以..这可能是一个愚蠢的问题.我无法完全了解为什么使用EF6 Async会提高性能,而不是在Task中包装同步EF6调用(假设db调用在Web API REST api方法中)

即,这是为什么:

//wrapping synch with asynch
return await Task.Run(() =>
{
    var albums = this.context.Albums
                .Where(x => x.Artist.ID == artist.ID)
                .ToList();
    return albums;
});

比这更糟糕的是:

//using async 
return await this.context.Albums
            .Where(x => x.Artist.ID == artist.ID)
            .ToListAsync();

注意:我已经阅读了这篇文章http://blogs.msdn.com/b/pfxteam/archive/2012/03/24/10287244.aspx,这似乎说(过度简化)"不要只包装同步方法,重写该方法更有效".

问题1,EF6异步实现是做什么的？我假设它在实现中使用异步I/O？

问题2(和我真正的问题) - 有人可以解释为什么这更好？在db操作完成之前,两个实现是否都不会导致请求线程自由处理其他请求？