小编nla*_*ker的帖子

我在VS2013 Ultimate调试器中遇到Entity Framework 6.0.1时遇到很多问题,当调试到针对实时SQL Server的代码进行单元测试时.

无法在调试器中查看包含实体的变量.例如,如果我对我的DbContext执行LINQ查询并刷新结果视图以实际执行查询,则结果值为"无法评估子项".如果我ToArray()它,那么现在变量是一个实体数组而不是IQueryable,数组中的每个结果都是"无法计算表达式".如果我将该数组中的单个实体值存储到变量并尝试查看它,我会得到"运行时此时拒绝评估表达式".

通常,F10通过涉及访问实体属性的行导致Visual Studio崩溃.

如果我正在对模拟的假DbSet运行测试,则不会发生这种情况.

这是一个已知的问题？有没有办法来解决这个问题？

我正在尝试更好地了解使用WCF代理时发生的情况.我无法理解当我关闭(或不关闭)代理时会发生什么.

• 当我在WCF代理上调用Close()或Abort()时会发生什么？有什么不同？
• 绑定类型之间有何不同(例如,无会话的BasicHttpBinding与会话中的某些内容)？
• 为什么Close()会抛出某些情况,为什么它会成为阻塞操作？

是否可以使用makecert或我可用于生成自己的测试证书的任何其他工具来设置密钥用法属性？

我感兴趣的原因是用于BizTalk Server AS2传输的证书需要使用数字签名的密钥用于签名和数据加密或密钥加密用于加密/解密,我想要使用此功能.

我看到如何使用makecert 设置增强的密钥使用属性,但不是密钥用法.

在VS2010,Silverlight 4,.NET 4中,我有一个WCF服务和一个Silverlight应用程序,而Silverlight正在访问该类,而不是使用添加服务引用,而是通过共享合同.当然,这意味着我在Silverlight类库中有合同,并且该服务具有对该库的项目引用.

奇怪的是,这会在引用上产生一个/!\图标,并出现警告:

无法引用项目"SilverlightClassLibrary1".引用的项目针对不同的框架系列(Silverlight)

但是,引用工作正常(我可以使用我的Silverlight应用程序中的界面)并构建正常.

这是一个错误吗？我的猜测是肯定的,因为警告是在说谎,如果你添加一个程序集引用而不是项目引用,它也会消失.我提交了一个错误,此处还有更多信息.

我创建了以下C#程序:

namespace dispose_test
{
    class Program
    {
        static void Main(string[] args)
        {
            using (var disp = new MyDisposable())
            {
                throw new Exception("Boom");
            }
        }
    }

    public class MyDisposable : IDisposable
    {
        public void Dispose()
        {
            Console.WriteLine("Disposed");
        }
    }
}

当我使用它时dotnet run,我看到以下行为:

• Windows:写入控制台的异常文本,"Disposed"打印~20秒后,程序退出.
• Linux:写入控制台的异常文本,程序立即退出."处置"从未写过.

Windows上的延迟很烦人,但是在Linux上根本没有调用Dispose()的事实令人不安.这是预期的行为吗？

编辑以下对话中的澄清/补充:

• 这不是特定的using/Dispose(),这只是一个特例try/finally.行为也通常发生try/finally- finally块未运行.我更新了标题以反映这一点.
• 我还检查了Dispose()通过将文件写入文件系统来执行,只是为了确保问题与stdout Dispose()在未处理的异常情况下运行之前与控制台断开连接无关.行为是一样的.
• Dispose()如果在应用程序中的任何位置捕获到异常,则会调用它.当应用程序完全未处理时会发生此行为.
• 在Windows上,长差距不是由于编译延迟.当异常文本写入控制台时,我开始计时.
• 我最初的实验是dotnet run在两个平台上进行的,这意味着单独的编译,但我也试过dotnet publish在Windows上直接运行两个平台上的输出,结果相同.唯一的区别是,当直接在Linux上运行时,在异常文本之后写入"Aborted(core dumped)"文本.

版本细节:

• dotnet --version - > 1.0.4.
• 编译为netcoreapp1.1,在.NET Core …

有些事情让我对MVVM感到困惑 - 如果我使用视图优先方法来构建我的对象(这似乎是最常见的方法,至少在经过多次阅读和搜索之后),我如何将上下文信息导入到视图模型中？

我已经看到许多类似问题的答案说"使用DI容器注入你的模型",但这对我没有帮助,所以我将提供一个小例子.

假设我的应用程序是PeopleEditor.它用于加载和编辑People对象,这些对象很复杂.当您加载应用程序时,您将获得一个主屏幕,将一堆人员加载到内存中 - 让我们说这些都可以通过我可以从我的容器中访问的集合进行访问.通过单击Person,您将进入编辑器屏幕.编辑器很复杂,因此这不是在一个屏幕上实现的简单的主 - 细节视图.

因此,在主屏幕上,当我单击一个人时,应用程序需要创建一个新视图和视图模型并显示视图.如果我首先通过容器创建viewmodel,我可以使用适当的person对象初始化它.这对我来说似乎很自然,所以我很难弄清楚为什么视图优先似乎是主要模式.我如何使用view-first方法执行此操作？该视图将创建viewmodel,它可以访问People的集合,但不知道它正在编辑哪个人.为清晰起见编辑:多人编辑可以同时存在,每个人编辑一个不同的人.

Prism 4.0 alpha的MVVM参考实现使用"状态处理程序",它基本上是应用程序用于在容器中存储构造函数参数的服务.它保存状态并调用ShowView,最终创建的viewmodel导入状态对象.这对我来说似乎很笨拙 - 就像它试图假装它松散耦合时,它真的不是.还有其他人有其他指导吗？

我刚刚开始使用EF,像下面这样的查询让我觉得很奇怪:

var departmentQuery =
                schoolContext.Departments.Include("Courses").
                OrderBy("it.Name");

具体来说,对我说的是"it.Name".当我使用LINQ to SQL进行工具时,几乎可以使用lambda指定查询构建器查询中的每个过滤器,例如,在这种情况下,d => d.Name.

我看到OrderBy有一些覆盖,它们返回一个返回IOrderedQueryable或IOrderedEnumable的lambda,但是那些显然没有获得可以数据绑定的ObjectResult所需的Execute方法.

毕竟我读过lambdas如何对这种东西如此有意义,以及如何将它们翻译成表达式树然后转换为目标语言,这对我来说似乎很奇怪 - 为什么我需要使用"it.Name" ？

来自ASP newb的超级简单问题：我正在使用一个仅供内部使用的ASP.NET网站，该网站全面使用Windows集成身份验证。我想与站点关联的角色基本上有三个：用户，经理和管理员。该站点对整个组织开放，因此经过身份验证的任何人都是用户，除非他们是经理或管理员。

管理员和管理员列表需要在数据库中，而不是在web.config中。该站点的角色信息与从用户的AD配置文件中可以学习到的信息没有任何关联。

我一直在迅速选择ASP.NET，并且我绝对有能力研究正确的解决方案，但是我希望有人可以在这里正确地开始我的工作。完成这项工作的最佳方法是什么？我想这涉及在集成身份验证的顶部使用角色提供程序，但是在我开始研究一百万个选项并可能选择错误的选项之前，我想我会在这里提出问题。

谢谢！

我觉得我仍然看到很多指导和建议,说明视图优先方法是在应用程序中获得Blendability的最佳方法.但是,使用d:DataContext,d:DesignData和d:DesignInstance,无论您的视图和视图模型如何连接在一起,Blendability的问题都不容易解决？

使用DesignInstance,您只需选择要在设计器中使用的具体ViewModel类型,就好像您已经拥有了视图优先组合.实际上,使用DesignInstance实际上可以比执行IsInDesignMode后空翻更好地分离关注点,或者只为真实视图模型中的设计支持创建默认构造函数 - 您可以从viewmodel类型继承或从公共接口类型继承以创建简单的"设计器" viewmodel,它完全受限于设计师.使用DesignData,您甚至不必这样做:您可以在XAML中以声明方式创建伪视图模型.

确实,在进行上述活动时需要很小的前期成本,但结果实际上比通过将设计数据与真实视图模型混合得到的结果更清晰.有什么我想念的吗？为什么Blendability仍然是一个如此大的问题？

在阅读之前,请知道我已阅读有关vanilla WCF,WCF数据服务和RIA服务之间差异的所有其他帖子.我的问题具体是为什么RIA Services被认为是专门针对Silverlight的一种特殊数据源,因为它似乎更有意义让它完成一项工作:充当REST接口背后的业务逻辑层.

看起来随着VS2010的发布,RIA Services巩固了其作为REST数据访问服务背后的业务逻辑层的立场 - 这似乎可以通过域服务类模板中的新"Expose OData Endpoint"选项得到证实. Visual Studio,据我所知,它本质上为你的RIA服务确实为WCFDS为任意数据源做了什么(我相信你可以做到这一点,我相信,但是这个复选框的添加清楚表明RIA服务可以是被视为包含业务逻辑的层,用于增强REST数据端点和/或将其约束到给定的查询集,而不一定是其自身的端点.

所以,如果我有一个业务逻辑的RIA服务,通过OData公开,我可以从WCF客户端应用程序添加对OData服务的引用.在客户端上,我获得了一个DataServiceContext派生物,它允许我在客户端上进行工作单元样式工作.我可以从Silverlight应用程序做同样的事情并获得看似相同的东西 - 一个DataServiceContext衍生物.

如果我在我的Silverlight应用程序中使用"RIA服务链接"直接将应用程序绑定到RIA服务而不是添加服务引用,我会获得Visual Studio生成的代码,它似乎支持几乎相同的工作模式,但是使用不同风格的API.

既然如此:

• "RIA服务链接"的优点是什么,其中Silverlight应用程序直接绑定到RIA服务,而不是仅将服务引用添加到任何类型的客户端可以使用而不会引起紧密耦合的OData端点？我被告知RIA的神奇之处在于代码生成,所以我想我正在努力理解RIA代码生成与"添加服务引用"代码生成的区别.
• 如果有优势,为什么这些优势专门针对Silverlight而非WCF客户端应用程序提供？将RIA服务纯粹作为OData端点背后的层来销售似乎有助于标准化和推动OData进一步成为任何类型客户端的通用类型端点 - "从ASP消耗,从Silverlight消耗,从WCF消耗......你获得了几乎相同的体验,而且它是一个很棒的体验."相反,我们将Silverlight与RIA直接绑定,具有一组特殊功能,以及所有其他使用开放协议的客户端.

我正在使用刚刚发布的最新.NET SDK(1.0.1,安装自https://dotnetcli.blob.core.windows.net/dotnet/Sdk/1.0.1/dotnet-dev-debian-x64 .1.0.1.tar.gz)用"dotnet发布"构建项目.由于除了这个问题范围之外的原因,我正在尝试构建应用程序,以便它们运行在稍微较旧版本的框架上(1.0.3和1.1.0,而不是最新的1.0.4和1.1.0).

如果我构建一个指定的项目,<TargetFramework>netcoreapp1.1</TargetFramework>它将不会在仅安装了1.1.0版的平台上运行.

看起来我可以<RuntimeFrameworkVersion>1.1.0</RuntimeFrameworkVersion>在每个项目的基础上在我的csproj中指定,但有没有办法我可以配置dotnet netcoreapp1.1,默认情况下定位目标1.1.0？

Microsoft的企业SSO服务器与BizTalk Server捆绑在一起 - 我非常熟悉如何配置它,确保它正常工作等等.我的任务是,它究竟做了什么,以及它是如何做到的？

我最好的理解是它用于安全地存储端口和适配器之类的配置,因为配置项通常包括诸如凭证,密码,连接字符串等等.就"它如何工作"而言,我最好的猜测是配置值以加密方式存储在SSO数据库中,"主密钥"只是加密密钥,只有特权凭证(如运行BizTalk主机的凭证)才能访问,因此可以使用它来访问加密配置.

有人可以对此有所启发,并指出这是对还是错？

Ye Olde添加Web引用会对使用事件的服务生成XXXAsync调用,以通知呼叫者呼叫已完成.

在WPF或控制台应用程序中添加服务引用,当被告知生成异步操作时,使用IAsyncResult设计模式(BeginXXX和EndXXX操作).我的理解是,这通常被认为是可用性和灵活性的一个进步 - 您可以使用回调,您可以通过调用EndXXX在任何时间点开始阻止,您可以对等待句柄进行分组并阻止一组操作,你可以投票等

为什么Silverlight中的ASR不使用IAsyncResult？我的猜测是因为设计人员想要非常清楚地表明事实上需要完全异步性,并且如果他们使用了IAsyncResult设计模式,那么尝试只需调用Begin然后紧跟End就太容易了.对于一个可能被大约100%的新开发者或者没有很好地掌握异步的人所击中的绊脚石.