小编RMD*_*RMD的帖子

我有一个C#Windows服务,我最近从.NET 3.5迁移到.NET 4.0.没有进行其他代码更改.

在3.5上运行时,给定工作负载的内存利用率约为1.5 GB内存,吞吐量为每秒20 X. (在这个问题的背景下,X无关紧要.)

在4.0上运行的完全相同的服务使用3GB到5GB +的内存,并且每秒小于4X.事实上,随着内存使用量继续攀升,该服务通常会停止运行,直到我的系统以99%的利用率选址并且页面文件交换变得疯狂.

我不确定这是否与垃圾收集有关,或者是什么,但我无法搞清楚.我的窗口服务通过下面的配置文件开关使用"Server"GC:

  <runtime>
    <gcServer enabled="true"/>
  </runtime>

将此选项更改为false似乎没有任何区别.此外,从我在4.0中的新GC上完成的阅读中,大的变化只影响工作站GC模式,而不影响服务器GC模式.因此GC可能与此问题无关.

想法？

我有一个相当稳定的服务器应用程序版本,已经在数十个客户中部署了将近一年.

一位新客户最近设置了该应用程序,并收到以下错误:

System.MethodAccessException:尝试通过安全透明方法[SomeMethod]访问安全性关键方法[SomeOtherMethod]失败.

SomeMethod和SomeOtherMethod都是我编写的程序集中的方法,这些方法是针对.NET 4构建的,并且是在Windows服务中运行的.如果它有所不同,SomeOtherMethod确实引用了针对.NET 2.0构建的第三方程序集(EntLib 4.1)中的类型.查看EntLib 4.1的代码,我确实看到它们同时使用SecurityTransparent和APTC属性,但这从未在其他客户端引起过问题.

这些程序集是从.NET 2.0 CLR升级的,但很久以前.这个确切的代码正好在其他客户上运行,我没有明确使用APTC属性,也没有在任何地方使用SecurityCritical属性.

这使我得出结论,这是一个配置问题或者.NET Framework补丁问题.是否有针对.NET发布的补丁会导致这种突破性变化？是否有一个配置设置在某些地方执行这种类型的检查,默认情况下是关闭但我的客户可能已启用？

最后一点.我的服务使用SSRS RDLC生成PDF.由于.NET 4中的一些更改,我必须通过以下配置强制服务使用旧版安全策略:

  <runtime>
    <NetFx40_LegacySecurityPolicy enabled="true" />
  </runtime>

有关我需要执行此操作的详细信息,请参阅此stackoverflow帖子:.NET 4.0中的内存使用率非常高

重要的是,我也在所有其他客户那里做到这一点.只有这一个客户遇到问题.

我正在尝试使用.NET System.DirectoryServices.AccountManagement库来获取特定Active Directory用户的UserPrincipal.

我有以下代码:

PrincipalContext context = new PrincipalContext(ContextType.Domain, "DomainName");
userPrincipal = UserPrincipal.FindByIdentity(context, IdentityType.SamAccountName, username);

此代码作为有效的域用户运行,但是当我执行它时,我得到以下异常:

System.DirectoryServices.DirectoryServicesCOMException(0x8007052E):登录失败:未知的用户名或密码错误.

有趣的是,我可以使用相同的上下文进行以下调用,没有问题:

context.ValidateCredentials(username, password, ContextOptions.Negotiate)

想法？

我读过有关Windows Azure中DiagnosticMonitor使用的WADLogsTable表是否会自动删除旧日志条目的相互矛盾的信息.

我猜它没有,而是会永远长大 - 花钱我.:)

如果是这种情况,是否有人有一个很好的代码示例,如何手动清除此表中的旧日志条目？也许基于时间戳？我会定期从worker角色运行此代码.

我正在使用VS 2015 Enterprise Update 1,尽管这也发生在更新1之前.

在某些时候,当我的解决方案配置了多个启动项目时,我变得无法执行CTRL + F5(无需调试启动).这些项目是什么并不重要 - 实际上,我可以在多项目对话框中选择一个项目,并且我得到相同的错误.

错误是:

没有调试就无法启动.启动项目无法启动.确保将正确的项目设置为启动项目.通过从解决方案资源管理器中的右键菜单中选择"设置为启动项目"命令,可以更改启动项目.

另外,请确保在项目属性中正确配置其调试设置.

我已经确认我可以用单个项目进行CTRL + F5,但从不使用多个项目.这发生在多个完全独立的解决方案中 - 因此似乎是Visual Studio的一些非解决方案/项目特定问题.

我也尝试在安全模式下运行Visual Studio,但没有任何区别.

我们将Release Management 2015与vNext发布模板一起使用.我们为应用程序的每个部分都提供了基于Powershell DSC的组件部署,事实上,我们正在部署两个不同的应用程序,这些应用程序处于活动开发阶段,并且通常几乎同时部署.

我们经常在部署期间收到以下错误:

OperationFailedException:不允许进行新部署,因为另一个部署正在进行中.有一段时间后重试部署.

完整的堆栈跟踪显示错误不是来自Powershell本身,而是来自负责在目标机器上执行powershell脚本的Release Management系统:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> Microsoft.TeamFoundation.Release.Common.Helpers.OperationFailedException: New deployment is not allowed as an another deployment is in progress. Retry the deployment after sometime.
   at Microsoft.TeamFoundation.Release.EnvironmentProvider.OnPrem.Implementation.OnPremDeploymentProvider.ReadDeploymentResponse(DeploymentResponse response)
   at Microsoft.TeamFoundation.Release.EnvironmentProvider.OnPrem.Implementation.OnPremDeploymentProvider.RunScript(String scriptPath, String configurationPath, MachineSpecification machine, StorageSpecification storage, Dictionary`2 configurationVariables)
   at Microsoft.TeamFoundation.Release.MonitorServices.Dsc.OnPrem.OnPremDeploymentActions.InvokePlatform(String activityId, MachineSpecification machineSpecification, StorageSpecification storageSpecification, String scriptPath, String configurationPath, Dictionary`2 configurationVariables)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, …

我正在使用TFS版本管理来进行持续集成和部署.

我在部署期间使用migrate.exe来执行数据库迁移,当您从旧版本迁移到较新版本时,这非常有用.但是,当您想要部署旧版本的应用程序时,它会变得更加混乱.

基本上,保存上下文迁移的程序集必须知道如何从第3版转到第2版.通常,您使用要部署的程序集作为迁移的源,但在这种情况下,您必须使用已部署的程序集,因为他们是唯一知道如何从v3下载到v2的人.(版本2不知道v3甚至存在.)

我目前的计划是在部署期间以某种方式比较两个程序集.如果安装目录中的程序集包含"部署控制器"中的"更新"迁移,我首先需要在部署目录中的程序集中获取"最新"可用迁移,然后执行:

migrate.exe AssemblyInInstallationDir /targetMigration NewestFromAssemblyInDeploymentDir

在您正在升级到较新版本的"正常"部署方案中,您可以这样做:

migrate.exe AssemblyInDeploymentDir

这是一种合法的做法吗？我还没有考虑使用EF库来评估每个程序集中可用的迁移.还存在这样的事实的挑战:这些组件中的每一个都是"相同"的不同版本.我可能需要将它们加载到单独的应用程序域中,然后使用跨应用程序域通信来获取我需要的信息.

编辑

我创建了一个概念验证应用程序,它允许我列出可用的迁移到同一程序集的两个不同版本.这对整个过程至关重要,所以我认为值得记录.

该应用程序使用反射来加载每个程序集,然后使用System.Data.Entity.Migrations中的DbMigrator类来枚举迁移元数据.迁移的名称以时间戳信息为前缀,从而允许我对它们进行排序并查看哪个程序集包含"更新"的迁移集.

static void Main(string[] args)
{
    const string dllName = "Test.Data.dll";
    var assemblyCurrent = Assembly.LoadFile(Path.Combine(System.Environment.CurrentDirectory, string.Format("Current\\{0}", dllName)));
    var assemblyTarget = Assembly.LoadFile(Path.Combine(System.Environment.CurrentDirectory, string.Format("Target\\{0}", dllName)));

    Console.WriteLine("Curent Version: " + assemblyCurrent.FullName);
    Console.WriteLine("Target Version: " + assemblyTarget.FullName);

    const string contextName = "Test.Data.TestContext";
    const string migrationsNamespace = "Test.Data.Migrations";
    var currentContext = assemblyCurrent.CreateInstance(contextName);
    var targetContext = assemblyTarget.CreateInstance(contextName);

    var currentContextConfig = new DbMigrationsConfiguration
    {
        MigrationsAssembly = assemblyCurrent,
        ContextType = currentContext.GetType(),
        MigrationsNamespace = migrationsNamespace …

我正在利用Automapper和Entity Framework中的Project功能,但我遇到的问题是Automapper似乎不想将一个枚举类型投射到另一个.

我有以下实体:

public class UserProfile
{
    public Guid Id { get; set; }
    public string Name { get; set; }
    private HashSet<UserProfilePhone> m_Phones;
    public virtual HashSet<UserProfilePhone> Phones
    {
        get { return m_Phones ?? (m_Phones = new HashSet<UserProfilePhone>()); }
        set { this.m_Phones = value; }
    }
}

public class UserProfilePhone
{
    public PhoneType Type { get; set; }
    public virtual string Number { get; set; }
}

public enum PhoneType
{
    Home = 1,
    Work = 2,
    Mobile = 3, …

我正在使用TFS 2015 Update 2发布管理(即"发布"选项卡),我的构建将所需的输出放在文件共享放置位置.它看起来像:

/Drop
--> /App 1
--> /App 2
--> /App 3

我的发行版定义有一个Powershell任务来部署每个应用程序.这很好用,因为上面的每个应用程序(App 1,App 2,App 3)都被定义为他们自己的工件,当我在找到要执行的powershell脚本时调出Linked Artifacts对话框时,我得到了很好的路径选择.

问题是当VSOAgent在给定的部署服务器上进行部署时,它会为整个版本定义下载所有链接的工件 - 无论它们是否被使用.因此,如果我有一个引用App 1的Powershell任务,我也会下载App 2和App 3.

在我的例子中,我的构建产生了许多工件,其中只有20%被部署到任何给定的环境中.所以我下载了一些我不需要的东西.实际上,这意味着应该采取的措施(并且DID采用旧版本管理)或许5分钟现在需要20分钟才能下载工件.

有办法防止这种情况吗？

我正在尝试使用 Azure 应用服务容器来托管 Azure DevOps Pipeline 代理。我的代理使用 Docker Desktop 在本地运行得很好，但当我将映像发布到应用服务时，启动命令永远不会执行。我被迫在容器中获取控制台并手动运行 powershell 脚本，然后该脚本将按预期工作。

这是我的泊坞窗文件：

FROM mcr.microsoft.com/windows/servercore:ltsc2019
RUN powershell Install-PackageProvider -Name NuGet -Force
RUN powershell Install-Module PowershellGet -Force
RUN powershell Install-Module -Name Az -Repository PSGallery -Force
RUN powershell Install-Module -Name Az.Tools.Migration -Repository PSGallery -Force
RUN powershell Enable-AzureRMAlias
WORKDIR /azp
COPY start.ps1 .
CMD powershell "c:\azp\start.ps1"

部署中心日志没有显示任何错误。就好像 CMD 从未运行过一样。