小编Dav*_*lls的帖子

具体来说,我正在评估页面上的所有图像以查看它们是否具有某个属性,然后根据这些属性向DOM添加一些新的<divs>.我必须等到document.ready才能执行这些修改,以确保Chrome已加载所有必要的DOM部分吗？

我遇到的问题是,有时document.ready需要一段时间才能触发并且用户已经在浏览页面,想知道为什么我的扩展程序还没有产生任何影响.这个问题通常只会持续一段时间,但这足以令人烦恼.

如果我不打扰等待document.ready,而是立即处理文档,一切似乎都有效; 但我想知道我是否只是幸运.

我们最近在我们的持续集成构建服务器上安装了.NET 4.5,以便它可以支持利用.NET 4.5功能的新项目.此构建服务器还用于构建和部署旧项目,其中一些目标是.NET 4.0.

针对在此服务器上构建的.NET 4.0,然后部署到仅安装了.NET 4.0的目标服务器的项目现在失败,并出现以下错误:

Method not found: 'Int32 System.Environment.get_CurrentManagedThreadId()'.

Environment.CurrentManagedThreadId是.NET Framework 4.5的新属性,因此运行4.0的服务器无法找到它.然而,我们都在构建时针对.NET 4.0,因此从理论上讲,我们不应该需要有安装在生产服务器上4.5.

总结一下:

• 项目目标4.0
• Build server已安装4.5
• 然后部署项目的服务器只有.NET 4.0
• 项目在运行时因错误而失败 Method not found: 'Int32 System.Environment.get_CurrentManagedThreadId()'.

是什么赋予了？在使用.NET 4.5的服务器构建dll时,是否可以在仅安装了.NET 4.0的服务器上成功运行.NET 4.0 dll？

我正在使用Google Maps v3 API,我有一个基于ImageMapType类的自定义叠加层.我想在加载叠加的瓷砖时显示某种加载指示,但我看不出有什么方法可以知道它们何时完成.

创建叠加层的代码类似于以下内容:

var myOverlay = new google.maps.ImageMapType({
    getTileUrl: myGetTileUrl,
    tileSize: new google.maps.Size(256, 256),
    isPng: true
});

myMap.overlayMapTypes.push(myOverlay);

以上工作正常,叠加成功加载; 它似乎没有地图发出任何事件来指示ImageMapType覆盖的状态.

我希望地图至少在瓦片完成加载时发出"空闲"事件,但据我所知,它没有.

我怎么知道ImageMapType覆盖完成加载的时间？

编辑

我在jsFiddle上写了一个测试用例:http://jsfiddle.net/6yvcB/ - 观察你的控制台输出中的"闲置"这个词来查看空闲事件何时触发.请注意,单击按钮添加叠加层时,它永远不会触发.

还有,小猫.

我有一个自定义的HttpHandler,我在其中手动启用输出压缩,如下所示:

context.Response.AppendHeader("Content-encoding", "gzip");
context.Response.Filter = new GZipStream(context.Response.Filter, CompressionMode.Compress);

这适用于大多数请求,但遇到异常时,"Content-encoding"标头会从响应中消失,而压缩过滤器仍保留在原位.结果是错误页面被gzip压缩,但是浏览器没有收到表示该事实的标题.然后浏览器尝试将仍然压缩的数据显示为文本,即gobbledygook.

完整的测试用例代码如下所示.尝试交替禁用压缩或不抛出异常.

有人可以解释为什么"内容编码"标题消失了吗？

我想我可以简单地启用压缩作为处理程序的最后一件事,因此如果遇到异常,它永远不会到达添加压缩过滤器的点; 但我看到的行为让我感到害怕.谁能确认一下？

public class TestHandler : IHttpHandler 
{
    public void ProcessRequest(HttpContext context)
    {
        CompressResponse(context);
        context.Response.Write("Hello world");

        // Throw an exception for testing purposes
        throw new Exception("Just testing...");
    }

    private void CompressResponse(HttpContext context)
    {
        string acceptEncoding = context.Request.Headers["Accept-Encoding"];
        if (String.IsNullOrEmpty(acceptEncoding))
        {
            return;
        }

        // gzip or wildcard
        if (acceptEncoding.ToLower().Contains("gzip") || acceptEncoding.Contains("*"))
        {
            context.Response.AppendHeader("Content-encoding", "gzip");
            context.Response.Filter = new GZipStream(context.Response.Filter, CompressionMode.Compress);
            return;
        }

        // Also handles deflate (not …

PresentationCore.dll和WindowsBase.dll都包含在Microsoft .NET Framework 3.0中,每个dll的两个版本都安装到磁盘:

• C:\ Program Files\Reference Assemblies\Microsoft\Framework\v3.0下的x64版本
• C:\ Program Files(x86)\ Reference Assemblies\Microsoft\Framework\v3.0下的x86版本

在添加对这些dll的引用之前,我们的ASP.NET Web应用程序能够针对"任何CPU"进行编译,并且可以在32位或64位模式下运行而不会出现问题.通过标准的"添加引用"对话框(添加引用 - > .NET - > PresentationCore)向PresentationCore添加引用后,Web应用程序在64位模式下失败,并出现以下错误:

无法加载文件或程序集"PresentationCore"或其依赖项之一.尝试加载格式不正确的程序.

显然这是因为64位应用程序池正在尝试加载32位版本的PresentationCore dll并且失败.

现在,我对此有点困惑......

1. 其他.NET Framework dll似乎无缝地在x64和x86版本之间切换(分别从Microsoft.NET/Framework64或Microsoft.NET/Framework加载).为什么PresentationCore和WindowsBase有什么不同？
2. 为什么Visual Studio似乎只在"添加引用"对话框的".NET"选项卡下提供32位版本？如果我想要64位版本,我必须"浏览"它.
3. 是否有任何简单的方法可以自动选择正确的dll,就像其他.NET Framework库一样？

我们总是可以编写一些MSBuild xml,它会在构建时根据目标环境的位数自动交换引用,但这似乎是我们不应该为.NET Framework dll做的事情.是什么赋予了？

谢谢!

我正在寻找一些关于某事的意见.请考虑以下来自名为的类的代码SomeApiObject:

// Property with private setter
public IList<string> SomeList
{
    get;
    private set;
}

// Constructor
public SomeApiObject()
{
    SomeList = new List<string>();
}

有了这个设置,类的用户SomeApiObject不能重新分配SomeList财产,但他们可以做的是通过使用诸如操纵现有列表Add(),Remove()和Clear().

这种模式的好处是保证属性永远不会出现null,这可以是一个非常方便的假设,因为用户正在使用API​​,因为这意味着用户可以总是迭代列表,获取列表的大小,或添加到它而无需检查null.

我看到一些缺点.例如,对于用户来说,通过操纵其内容可以写入该列表并不一定是显而易见的.另一方面,我可以设想,操作列表在语法上不太方便,或者在性能上可能比分配新列表更差.

我和这个人在一起,我正在征求意见.

• API的用户潜在的缺点是否过于令人讨厌？
• 保证永远不会null像我想的那样漂亮吗？

编辑:

我已经确信使用某种"永不空"模式的好处.我更感兴趣的是有人扮演魔鬼的拥护者,并告诉我为什么在API的用户的角度来看,在列表上设置一个私人的二传手可能会令人讨厌和/或禁止.

我不久前发布了一个.NET API包装器,到目前为止,一些用户对如何为这样的属性赋值给出了混淆.