小编And*_*ens的帖子

我刚刚开始使用NHibernate 3.2及其"按代码映射"功能,并将我们的Fluent映射迁移到它.是否有一个流利的"ReadOnly();" 功能,使整个映射只读？提前致谢.

我正在开发一个WPF应用程序,但我注意到在某些字体大小的情况下,文本的渲染效果不如您在控制面板 - >字体中看到的样本.我正在使用大型Segoe UI字体(FontSize="36"),并且在直立线上效果更明显,例如字母"U"可能在一侧比另一侧稍厚.).

字体质量在某些字体大小FontSize="48"上有所改善,例如(我认为相当于36pt),但使用有限数量的字体大小并不总是实用的.

我可以通过将以下属性应用于TextBlock来提高字体质量: -

TextOptions.TextFormattingMode="Display" TextOptions.TextRenderingMode="ClearType"

鉴于质量的提高,我很想知道为什么WPF不会为所有文本执行此操作,还是归结为性能？我正在考虑创建一个全局样式以将其应用于所有控件,或者这会导致问题吗？

(我尝试上传截图,但SO必须以低质量存储图像,而你无法确定字体问题).

我正在使用温莎城堡，并且在大多数情况下，我是通过类构造函数使用DI的。但是，有时我发现自己使用服务定位器来解析类型的实例，我知道这是一种反模式。我相信您还必须释放以这种方式解析的瞬态对象，因为温莎不会为您这样做吗？

一个示例场景是模拟电视遥控器的类。UI具有许多按钮，单击一个按钮将导致类实例化并执行特定的“命令”对象。通过构造函数注入所有这些具体命令显然是不可行的，因此我将使用服务定位器，如下所示：-

private void PowerButtonOnClick()
{
    var command = ServiceLocator.Current.Resolve<IPowerOnCommand>();
    command.Execute();
}

我将如何重构代码以摆脱服务定位器，并确保完成后释放临时类型（如果Windsor确实需要这样做）？

（我意识到上述场景可以使用“命令”设计模式来解决。这只是一个示例场景-在其他情况下，我正在使用服务定位器）。

我刚刚开始使用SignalR,并为SignalR创建了一个自定义解析器,因此我可以使用Castle Windsor通过集线器构造器注入依赖项.

我有点假设我只需要注册依赖项,但我发现在我的应用程序工作之前还必须自己注册集线器.这是预期的吗？如果是这样,我应该用什么寿命用于集线器？

我一直对“模型”应该或不应该包含什么感到有点困惑 - 教程和示例经常相互矛盾。到目前为止，我一直在谨慎行事，我的模型仅公开“UI 内容”，例如用于绑定到视图的属性以及验证逻辑。但是模型中包含其他业务逻辑是否可以接受？

假设我想通过网络服务控制机械泵，该服务提供了以给定速度打开泵以及再次关闭泵的方法。我的 UI 视图可能包括“开”和“关”按钮，以及一个用于设置速度的文本框。考虑到这一点，我的模型可能会这样开始：-

public class Pump
{
    public int Speed { get; set; }
}

// The real thing would implement INotifyPropertyChanged, validation, etc.

这是模型应该做的全部事情吗？或者公开用于打开和关闭泵的业务逻辑是否可以接受 - 或者作为视图模型调用的方法，或者甚至作为可以直接绑定到视图的 ICommand纽扣？或者所有这些都应该在视图模型中？

编辑 不知道为什么投反对票，因为我认为这是一个完全合理的问题。虽然网络上有许多 MVVM 教程和示例，但它们经常提供关于什么去哪里的相互矛盾的建议，就像下面提供的答案一样。我什至最终阅读了 WPF 专家 Josh Smith 撰写的“高级 MVVM”电子书 - 这本书没有提到任何模型！

不管怎样，我在这里为任何想要了解 MVVM 结构的人找到了一个很好的资源。虽然该链接将带您进入 Microsoft Prism 框架的文档，但此特定页面全部是关于 MVVM 结构，很少或没有 Prism 特定内容。我发现该页面内容非常丰富，至少让我安心，确认我在过去几年中所做的事情是完全有效的 - 也就是说，拥有实现 INPC 和验证的模型 (IDataErrorInfo) ，并通过 VM 属性将这些模型直接绑定到视图（而不是像下面的一些答案所提倡的那样，在 VM 中重复模型属性）。

我正在尝试将 ItemTemplate 和 ItemContainerStyle 应用于 ItemsControl：-

<ItemsControl ItemsSource="{Binding LogEntries}"
              ItemTemplate="{StaticResource itemTemplate}"
              ItemContainerStyle="{StaticResource itemContainer}" />

然而 ItemContainerStyle 似乎被忽略了（但如果我删除了 ItemTemplate 它确实有效）。

项目模板相当复杂，用于许多不同的视图。在一个特定视图中，我需要更改列表项的间距和背景颜色，因此我还尝试应用 ItemContainerStyle，如下所示：-

<Style x:Key="itemContainer"
       TargetType="ContentPresenter">
    <Setter Property="ContentTemplate">
        <Setter.Value>
            <DataTemplate>
                <Border x:Name="itemBorder"
                        Margin="4,0,4,4"
                        Background="#666666">
                    <ContentPresenter Content="{Binding}" />
                </Border>
            </DataTemplate>
        </Setter.Value>
    </Setter>
</Style>

我有点惊讶你不能同时申请，除非我遗漏了什么？我认为 ItemContainerStyle 实际上只是项目内容的“包装器”，无论项目的内容是否模板化？

我通过开发一个相当大的WPF应用程序,通过串行通信来控制一个复杂的硬件,这是一个很好的方法.在应用程序"堆栈"的最底部,我有一个串行通信层(利用.Net'SerialPort'类).读取和写入h/w设备是系统的基本部分,由业务逻辑层的许多不同区域使用,通常散布着复杂的科学计算和其他这样的逻辑; 这些BLL方法又从整个UI层调用.

目前,业务逻辑层中的所有内容(包括SerialPort读写)都是同步的.我使用async/await的唯一一次是在UI层,通常是在调用业务逻辑时.在这里我将打电话Task.Run(),例如: -

private async void SomeButtonClick(object sender, EventArgs e)
{
    await Task.Run(() => _someBLLService.TurnPumpOn());
}

这是一个需要几毫秒的简单示例.一个更复杂的例子是开始一个长期运行的过程(再次使用上述技术); 此业务逻辑"服务"将运行几秒或几分钟,从硬件收集数据并在此期间执行其他"控制"功能.它会定期将数据广播回UI,以便在图表上绘图(通过pubsub事件聚合器框架).上述技术运行良好,允许UI在发生此类业务层进程时保持响应.

我最近一直在考虑从串行通信代码(例如使用.ReadAsync)开始"一路异步" ,但这会对整个系统产生影响.数十个(如果不是数百个)业务逻辑方法需要重构为异步方法,直到UI层.在这里,我可以稍微简化上面的代码:

private async void SomeButtonClick(object sender, EventArgs e)
{
    await _someBLLService.TurnPumpOn();
}

虽然我不反对解决大型重构工作,但我想知道它的好处是什么.很多人(比如Stephen Cleary)主张"异步一路"解决方案,但主要目标似乎是在调用长时间运行的BLL进程时保持UI响应,这是我的Task.Run()技术已经做到的.

刚刚切换到VS2019我\xe2\x80\x99m探索是否使用代码分析。在项目属性\xe2\x80\x9c代码分析\xe2\x80\x9d选项卡中，有许多内置的Microsoft规则集，当我的代码违反这些规则之一时，我可以看到编辑器出现波形曲线。我可以自定义这些规则集并将 \xe2\x80\x9csave 为 \xe2\x80\x9d 来创建我自己的规则集。

我还看到了代码分析器 NuGet 包，例如 \xe2\x80\x9cRoslynator\xe2\x80\x9d 和 \xe2\x80\x9cStyleCop.Analyzers\xe2\x80\x9d。这些和内置的 MS 规则有什么区别？真的只是因为更全面的规则/更多的选择吗？

如果我想坚持使用内置的 MS 规则，有什么限制吗？例如，它们是否仍会在 TFS/Azure DevOps 构建期间运行并被报告？

多年来，我们一直将 IronPython 用作一些 .Net 桌面应用程序中的脚本工具。客户一直在询问我们何时会支持 Python 3，但看起来 IronPython3 仍有很长的路要走（https://github.com/IronLanguages/ironpython3）。我刚刚找到了一个名为 Python.Net 的库，并想知道它与 IronPython 有多相似，我们是否可以转移到它？

大多数 Python.Net 示例展示了如何在 Python 代码中使用 .Net 类型，我找不到任何关于如何在 C# 中实际运行 Python 代码的好示例。页面末尾有一个标题为“嵌入 Python”的部分 ( http://pythonnet.github.io/ )，但没有详细介绍。

我很想知道如何从文件或字符串运行脚本，脚本是否可以“编译”（如 IronPython），大概“变量”可以像 IronPython 作用域一样来回传递？是否有任何限制或已知问题？Python.Net 是否允许运行引用库（例如 numpy）的脚本？（我们无法在 IronPython 上使用它，我认为这是因为它包含编译的 (.pyc) 代码，而 IP 不支持该代码）。

有没有人对两者都有经验，并且能够提供一些关于它们如何比较的见解？

我有一个 .Net Framework WPF 应用程序，目前正在迁移到 .Net6。启动时，它会检查可执行文件夹中的某些程序集，查找具有自定义程序集属性的程序集。然后，那些具有此功能的应用程序将被加载到当前的应用程序域中。（请注意，其中一些程序集可能已经位于应用程序域中，因为它们是正在运行的应用程序的解决方案中的项目）。

这是 4.x 代码：

private void LoadAssemblies(string folder)
{
    AppDomain.CurrentDomain.ReflectionOnlyAssemblyResolve +=
        (s, e) => Assembly.ReflectionOnlyLoad(e.Name);

    var assemblyFiles = Directory.GetFiles(folder, "*.Client.dll");
    foreach (var assemblyFile in assemblyFiles)
    {
        var reflectionOnlyAssembly = Assembly.ReflectionOnlyLoadFrom(assemblyFile);
        if (ContainsCustomAttr(reflectionOnlyAssembly))
        {
            var assembly = Assembly.LoadFrom(assemblyFile);
            ProcessAssembly(assembly);
        }
    }
}
  

自定义程序集属性（此代码正在查找）具有一个字符串属性，其中包含该程序集中 XAML 资源文件的路径。该ProcessAssembly()方法将此资源文件添加到应用程序的合并字典中，如下所示：

var resourceUri = string.Format(
    "pack://application:,,,/{0};component/{1}",
    assembly.GetName().Name,
    mimicAssemblyAttribute.DataTemplatePath);

var uri = new Uri(resourceUri, UriKind.RelativeOrAbsolute);
application.Resources.MergedDictionaries.Add(new ResourceDictionary { Source = uri });

重申一下，所有这些都在 .Net 4.x 应用程序中正常工作。

另一方面，.Net6不支持仅反射加载，也不能创建第二个应用程序域来加载程序集。我重写了上面的代码，将正在检查的程序集加载到我所理解的临时的、可卸载的上下文中：

    private void …