nuget 命令上传的时候报错method not allowed 405

产生这个错误是由于IIS安装了WebDAV模块

删除WebDAV Module与WebDAV Hanlder，上传时会返回404错误，通过浏览器访问路径nuget/Packages也是404错误。

查看IIS日志发现nuget push实际执行的是HTTP PUT操作 —— PUT /api/v2/package/，WebDAV不允许这个操作。

根据网上的说法，必须要卸载WebDAV，可是这台服务器上有一个站点需要它，后来将NuGet Server安装到另外一台服务器解决了这个问题。

　　OWIN 的全称是 "Open Web Interface for NET"， OWIN 在 NET Web 服务器和 NET Web 应用之间定义了一套标准的接口， 其目的是为了实现服务器与应用之间的解耦， 鼓励为 NET Web 应用开发简单模块。

　　OWIN 是一个开源开放的标准， 有助于建设 NET 开发的开源生态环境，OWIN 定义了如下几个概念：

服务器 (Server)

HTTP 服务器直接与客户端交互， 并用 OWIN 语义处理请求，服务器需要一个适配层将客户请求转换 成 OWIN 语义。 支持 OWIN 的服务器有 Katana 和 Nowin 。

Web 框架 (Web Framework)

构建在 OWIN 之上的自包含的独立组件， 向 Web 应用提供可用的对象模型或者接口。 Web 框架可 能需要一个适配层来转换 OWIN 语义。 支持 OWIN 的 Web 框架有：

Nancy

SignalR

WebApi

FubuMVC

SimpleWeb

DuoViaHttp

Web 应用 (Web Application)

一个特定的 Web 应用， 通常构建在 Web 框架之上， 使用 OWIN 兼容的服务器运行。

中间件 (Middleware)

特定目的的服务器和应用之间的可插拔组件， 可以监视、 路由、 修改请求与响应。

宿主 (Host)

应用与服务器所在的进程， 主要负责应用的启动， 有些服务器自身也是宿主， 比如 Nowin 。

　　为什么使用 OWIN

　　正如上面所说， OWIN 定义了 NET Web 服务器与 NET Web 应用之间的标准接口， 将应用与服务器 解耦， 使得便携式 NET Web 应用以及跨平台的愿望成为现实， 标准的 OWIN 应用可以在任何 OWIN 兼容的服务器上运行， 不再依赖与 Windows 和 IIS 。

　　怎么使用 OWIN

　　OWIN 通过 NuGet 包的形式发布， 获取和使用都非常方便。 下面就先建立一个最简单的 OWIN 应用：

打开 Xamarin Studio， 新建一个 C# 命令行程序， 如下图所示：

OWIN Hello

然后打开项目属性， 确认目标框架设置为 Mono/NET 45 ， 如下图所示：

向项目中添加如下几个 NuGet 包：

Owin

MicrosoftOwin

MicrosoftOwinHosting

MicrosoftOwinHostHttpListener

添加一个 OWIN Startup 类， 代码如下：

public class Startup {

public void Configuration(IAppBuilder appBuilder) {

appBuilderRun(HandleRequest);

}

static Task HandleRequest(IOwinContext context) {

contextResponseContentType = "text/plain";

return contextResponseWriteAsync("Hello, world!");

}

}

OWIN 约定的处理请求的代理类型是：

Func<IOWinContext, Task> handler

对应上面 Startup 类的 HandleRequest 方法， 所以上面的 Startup 类就定义了一个最简单的 OWIN 应用， 向客户端输出 Hello， World！

在自动生成的 Programcs 文件中的 Main 方法中添加如下代码， 来启动 OWIN 应用：

class MainClass {

public static void Main(string[] args) {

var url = "http://localhost:8080/";

var startOpts = new StartOptions(url) {

};

using (WebAppStart<Startup>(startOpts)) {

ConsoleWriteLine("Server run at " + url + " , press Enter to exit");

ConsoleReadLine();

}

}

}

现在开始运行程序， 命令行显示如下：

打开浏览器， 访问 http://localhost:8080/ ， 得到的响应如下：

OWIN Hello

　　到目前为止， 没有 Windows ， 更没有 IIS ， OWIN 应用就能正常运行了。

UWP (通用 Windows 平台) 应用开发者在构建通过 HTTP 与 Web 服务或服务器断点交互的应用时，有多种 API 可以选择。要在一个托管 UWP 应用中实现 HTTP 客户端角色，最常用也是推荐的两种 API 即 SystemNetHttpHttpClient 和 WindowsWebHttpHttpClient 。 相对于 WebClient 以及 HttpWebRequest 等老旧过时的 API，应当优先选择上述两种 API（尽管出于向后兼容的考虑， HttpWebRequest 的一个小子集在 UWP 中仍然可用）。

很多开发对于 UWP 中的上述两个 API 有着功能异同、如何选择等疑问。本文旨在解答这些疑问并阐明两个 API 各自的用途。

概述

SystemNetHttpHttpClient 这一 API 在 NET 45 中被首次引入，同时也有一个变体以 NuGet 包的形式为 NET 40 以及 Windows Phone 8 Silverlight 应用提供支持。该 API 的目的在于提供一种比老旧的 HttpWebRequest API 更为简单明了的抽象层，以及更为弹性灵活的 HTTP 客户端角色的实现方法。例如，开发者可以通过其提供的链式自定义 handler，拦截每个请求或响应并实现自定义逻辑。直到 Windows 81 位置，该 API 的底层都是由纯 NET 实现的。在 Windows 10 中，该 API 的 UWP 实现已经改为基于 WindowsWebHttp 和 WinINet HTTP 协议栈实现了。

另一方面， WindowsWebHttpHttpClient API 则在 Windows 81 被引入，并同时可用于 Windows Phone 81。创建这一 API 的最大动因在于整合各种 Windows 应用开发语言可用的 HTTP API，使一种 API 能够提供这些语言各自 API 的全部特性。其中大部分基础 API 的设计均来源于 SystemNetHttp ，而其实现则是基于WinINet HTTP 协议栈。

在 Windows 商店应用中使用上述两种 API时，操作系统版本以及编程语言的支持情况如下：

API 操作系统版本 支持语言

SystemNetHttpHttpClient Windows, Windows Phone 8 以上 仅限 NET 语言

WindowsWebHttpHttpClient Windows, Windows Phone 81 以上 所有 Windows 商店应用语言

如何选择？

两种 API 在 UWP 中均可用，因而 HTTP 开发者面临的最大问题就是该在应用中选择二者中的哪一种。选择结果要依一些具体因素而定。

你是否需要整合原生 UI 以收集用户凭据、控制 HTTP 患侧读写行为或传递指定 SSL 客户端证书用于验证？如果是，则使用 WindowsWebHttpHttpClient 。截至撰写本文时，相对于 SystemNetHttp API， WindowsWebHttpHttpClient API 提供了更多对 HTTP 设置的掌控能力。未来 SystemNetHttp API 可能也会得到加强以提供这些特性。

你是否要编写跨平台 NET 代码（通用于 UWP/ASPNET 5/iOS 以及 Android 平台）？如果是，则使用 SystemNetHttp API。使用该 API 编写的代码可以在 ASPNET 5 以及 NET Framework 桌面应用程序等其它平台上复用。感谢 Xamarin，如今该 API 也支持在 iOS 和 Android 平台上使用，所以你的代码也可以在这些平台上复用。

对象模型

现在我们已经了解了创建这两个相似 API 的原因以及如何选择的基本原则，接下来深入了解一下它们各自的对象模型。

SystemNetHttp

该 API 对象模型的顶级抽象层是 HttpClient 对象。 HttpClient 对象表示 HTTP 协议描绘的客户端-服务端模型中的客户端实体。客户端可以向服务端发送多个请求（由HttpRequestMessage 表示）并接收相应的响应（由 HttpResponseMessage 表示）。每个 HTTP 请求或响应的 entity body 和 content header 由基类 HttpContent 及其派生类 StreamContent 、 MultipartContent 和 StringContent 等表示。这些类型分别代表了不同类型的 HTTP entity body。这些类型均提供了一组 ReadAs 方法将一个请求或响应的 entity body 读出为字符串、字节数粗或流。

每个 HttpClient 对象底层均有一个 handler 对象表示所有客户端 HTTP 相关设置。你可以从概念上把 handler 理解为客户端底层的 HTTP 栈。它负责把客户端的 HTTP 请求发送至服务器并传回相应的响应。

SystemNetHttp API 中默认使用的 handler 类是 HttpClientHandler 。当你创建一个 HttpClient 对象的新实例时——例如，调用 new HttpClient() ——一个 HttpClientHandler 对象都会自动创建，并携带默认的 HTTP 栈设置。如果你想要修改缓存行为、自动压缩、凭据或代理等设置，你可以自己创建 HttpClientHandler的实例，修改其相应属性再传递给 HttpClient 的构造函数：

HttpClientHandler myHandler = new HttpClientHandler();

myHandlerAllowAutoRedirect = false;

HttpClient myClient = new HttpClient(myHandler);

链式 Handler

SystemNetHttpHttpClient API 设计中的一个关键优势就是可以在一个 HttpClient 对象底层插入自定义 handler，并创建一条 handler 对象链。假设你要构建一个需要从 Web 服务查询数据的应用。你编写了自定义逻辑来处理从服务器返回的 HTTP 4xx（客户端错误） 和 5xx（服务端错误） 错误，并发起更换端点或添加用户凭证等重试动作。而你也想要将这部分与 HTTP 相关的工作与其它处理 Web 服务返回数据的业务逻辑分开。

要实现上述需求，可以从 DelegatingHandler 派生一个新的 handler 类（例如 CustomHandler1），再创建一个派生类的实例传递给 HttpClient 的构造函数。 DelegatingHandler 类的 InnerHandler 属性用于指定链中的下一个 handler ——举例，你可以借此把另一个自定义 handler （例如 CustomHandler2）添加到链中。而在最后一个 handler 里，你可以把 InnerHandler 设置为一个 HttpClientHandler 实例，该实例会将请求传递给系统的 HTTP 栈。过程如下图所示：

完成上述需求的示例代码：

public class CustomHandler1 : DelegatingHandler

{

// 此处放置构造和其它代码。

protected async override Task<HttpResponseMessage> SendAsync(

HttpRequestMessage request, CancellationToken cancellationToken)

{

// 在此处理 HttpRequestMessage 对象。

DebugWriteLine("Processing request in Custom Handler 1");

// 一旦前步骤完成，调用 DelegatingHandlerSendAsync 继续将其传递至 inner handler

HttpResponseMessage response = await baseSendAsync(request, cancellationToken);

// 在此处理返回的 HttpResponseMessage 对象。

DebugWriteLine("Processing response in Custom Handler 1");

return response;

}

}

public class CustomHandler2 : DelegatingHandler

{

// 内容与 CustomHandler1 类似

}

public class Foo

{

public void CreateHttpClientWithChain()

{

HttpClientHandler systemHandler = new HttpClientHandler();

CustomHandler1 myHandler1 = new CustomHandler1();

CustomHandler2 myHandler2 = new CustomHandler2();

// 将两个 Handler 链接在一起。

myHandler1InnerHandler = myHandler2;

myHandler2InnerHandler = systemHandler;

// 使用链中的顶级 Handler 创建客户端对象。

HttpClient myClient = new HttpClient(myHandler1);

}

}

注意：

如果你打算向一个远程服务器端点发送请求，通常链中的最后一个 handler 都是 HttpClientHandler ，该 handler 负责实际通过系统的 HTTP 栈发送请求并接收响应。 若非如此，你可以使用一个自定义 handler 模拟发送请求以及接收模拟响应的过程。

在将请求传递到下一个 handler 之前，或在前一个返回响应之前添加处理逻辑可能会带来性能损失。在这类场景中最好避免开销昂贵的同步操作。

有关链式 Handler 的更多信息，可以参阅 Henrik Nielsen 撰写的 文章 （注意该文中谈及的 API 是指 ASPNET Web API 版本的，与我们在本文中谈论的 NET Framework 版略有区别，不过有关链式 handler 的概念是通用的。）

WindowsWebHttp

WindowsWebHttp API 的对象模式与上文中描述的 SystemNetHttp 非常类似，它也有客户端实体、handler（该命名空间内叫做 "filter"，即过滤器）以及在客户端与系统默认 filter 之间插入自定义逻辑等概念。

本 API 中大部分类型与 SystemNetHttp 的对象模型类似：

HTTP 客户端角色表示 SystemNetHttp 类型 对应 WindowsWebHttp 类型

客户端实体 HttpClient HttpClient

HTTP 请求 HttpRequestMessage HttpRequestMessage

HTTP 响应 HttpResponseMessage HttpResponseMessage

HTTP 或响应的 entity body HttpContent IHttpContent

HTTP 内容的字符串、流等表示 StringContent, StreamContent and ByteArrayContent HttpStringContent, HttpStreamContent and HttpBufferContent respectively

HTTP 栈/设置 HttpClientHandler HttpBaseProtocolFilter

用于创建自定义 handlers/filters 的基类/接口 DelegatingHandler IHttpFilter

上文中关于 SystemNetHttp API 链式 handler 的讨论亦可用于 WindowsWebHttp API。你可以创建一组链式自定义 filter，传递给 HttpClient 对象的构造函数。

实现常见 HTTP 场景

现在我们来看看一些代码片段，分别使用两种 HttpClient API 实现常见 HTTP 场景。更多细节和指导可以查阅 WindowsWebHttpHttpClient 和 SystemNetHttpHttpClient 的 MSDN 文档。

修改头

SystemNetHttp:

修改 HttpClient 实例发出的所有请求的头：

var myClient = new HttpClient();

myClientDefaultRequestHeadersAdd("X-HeaderKey", "HeaderValue");

myClientDefaultRequestHeadersReferrer = new Uri("http://wwwcontosocom");

只修改特定请求的头：

HttpRequestMessage myrequest = new HttpRequestMessage();

myrequestHeadersAdd("X-HeaderKey", "HeaderValue");

myrequestHeadersReferrer = new Uri("http://wwwcontosocom");

WindowsWebHttp:

上述代码同样适用于 WindowsWebHttp API。

注意：

部分头项目是集合，修改需要通过 Add 和 Remove 方法实现。

HttpClientDefaultRequestHeaders 属性表示在应用层次上，默认头集合是否会添加到请求中。由于请求是由系统的 HTTP 栈处理的，所以请求实际发送出去前，一些附加头可能会添加到请求中。

超时设置

SystemNetHttp:

在 SystemNetHttp API 中，有两种方式设置超时。要为客户端发出的所有请求设置超时，使用：

myClientTimeout = TimeSpanFromSeconds(30);

要为单个请求设置超时，则使用 CancellationToken:

var cts = new CancellationTokenSource();

ctsCancelAfter(TimeSpanFromSeconds(30));

var httpClient = new HttpClient();

var resourceUri = new Uri("http://wwwcontosocom");

try

{

HttpResponseMessage response = await httpClientGetAsync(resourceUri, ctsToken);

}

catch (TaskCanceledException ex)

{

// 因超时取消请求的逻辑

}

catch (HttpRequestException ex)

{

// 处理其它可能异常的逻辑

}

WindowsWebHttp:

WindowsWebHttpHttpClient 类型中没有超时属性可用，因此你必须向上文一样使用 CancellationToken 实现超时处理。

使用身份验证凭据

SystemNetHttp:

为了保护用户的凭证信息，HTTP 栈默认不会向发出的请求添加任何验证凭据。要使用指定用户的凭据，可以使用如下方法：

var myClientHandler = new HttpClientHandler();

myClientHandlerCredentials = new NetworkCredential(myUsername, myPassword);

WindowsWebHttp:

对于 WindowsWebHttp API，默认情况下如果发出的请求访问了要求用户验证的资源，系统会弹出一个 UI 对话框。要关闭 UI 对话框，可以把 HttpBaseProtocolFilter 的 AllowUI 属性设置为 false。要使用指定用户的凭据，可以使用如下方法：

var myFilter = new HttpBaseProtocolFilter();

myFilterServerCredential = new PasswordCredential(“fooBar”, myUsername, myPassword);

注意：

在上述示例中， myUsername 和 myPassword 两个字符串变量可以来自用户通过 UI 输入或者应用自身的配置。

在 UWP 应用中， HttpClientHandlerCredentials 只能设置为 null、 DefaultCredentials 或一个 NetworkCredential 类型的对象实例。

使用客户端证书

SystemNetHttp:

为保护用户的凭据信息，该 API 默认不会向服务器发送任何客户端证书。要使用客户端证书用于验证，使用如下方法：

var myClientHandler = new HttpClientHandler();

myClientHandlerClientCertificateOptions = ClientCertificateOptionAutomatic;

WindowsWebHttp:

使用该 API 进行客户端证书验证有两种选择——默认方式是弹出一个 UI 让用户选择证书；另一种选择是在代码中自行指定一个客户端证书：

var myFilter = new HttpBaseProtocolFilter();

myFilterClientCertificate = myCertificate;

注意：

无论使用哪种 API ，要使用客户端证书，你必须先根据 这些步骤 将证书添加到应用的证书储存区。拥有企业权限的应用也能够使用用户的“我的”储存区中已经存在的证书。

HttpClientHandlerClientCertificateOptions 属性允许两种值： Automatic 和 Manual 。设置为 Automatic 则会从应用的证书储存区自动选择最佳匹配的证书用于验证。设置为 Manual 则会保证在服务器请求前，任何客户端证书都不会被发送。

代理设置

默认情况下，两种 API 的代理设置都会自动根据 Internet Explorer/ Microsoft Edge 的设置自动为所有 HTTP 调用进行配置。这使得应用在用户通过代理连接网络时也能正常工作。两种 API 都没有提供任何方法为应用指定一个自定义代理。然而你可以通过在 SystemNetHttp 中设置 HttpClientHandlerUseProxy 为 false 或在 WindowsWebHttp 中设置 HttpBaseProtocolFilterUseProxy 为 false 来禁止使用默认代理配置。

Cookie 处理

默认情况下，两种 API 都会保存服务器发来的 cookie 数据，并自动附加到随后产生的请求对相同应用容器 URI 的请求中。对特定 URI 的 cookie 也能读取或添加自定义 cookie 数据。最后，两种 API 都提供了选项来关闭向服务器发送 cookie：对于 SystemNetHttp ，将 HttpClientHandlerUseCookies 设置为 false；对于 WindowsWebHttp ，设置 HttpBaseProtocolFilterCookieUsageBehavior 为 HttpCookieUsageBehaviorNoCookies 。

SystemNetHttp:

为客户端生成的所有请求添加一个 cookie：

// 手动添加cookie。

myClientHandlerCookieContainerAdd(resourceUri, myCookie);

为单个请求添加 cookie：

HttpRequestMessage myRequest = new HttpRequestMessage();

myRequestHeadersAdd("Cookie", "user=foo; key=bar");

查看给定 URI 的所有 cookie：

var cookieCollection = myClientHandlerCookieContainerGetCookies(resourceUri);

WindowsWebHttp:

为客户端生成的所有请求添加一个 cookie：

// 手动添加cookie。

filterCookieManagerSetCookie(myCookie);

上文中为单个请求添加 cookie 的示例同样适用于 WindowsWebHttp API。

管理 cookie：

// 获取给定 URI 的所有 cookies。

var cookieCollection = filterCookieManagerGetCookies(resourceUri);

// 删除一个 cookie。

filterCookieManagerDeleteCookie(myCookie);

注意：

在 WindowsWebHttp API 中，对于应用容器内的 WindowsWebSyndication 、 WindowsWebAtomPub 以及 XHR 等几个使用 WinINet 栈实现的网络 API之间，cookie 管理器内的 cookie 数据是共享的。因此，之前一个 Syndication API 调用通过服务器响应获得 cookie 可能会被添加到相同应用容器内之后发送给同一服务器的 HttpClient 请求里。

每服务器最大连接数

默认情况下，操作系统底层的 HTTP 栈对每个服务器最多使用六个连接。 SystemNetHttp 的 HttpClient API没有提供任何方法控制最大连接数。对于 WindowsWebHttp API，可以使用如下方法设置：

var myFilter = new HttpBaseProtocolFilter();

myFilterMaxConnectionsPerServer = 15;

　在本文中 我将介绍使用 LESS Framework 动态生成 CSS 内容的 Web 开发

　毫无疑问 CSS 代表一大飞跃 它有望将内容与网页显示完全分离 而且在很大程度上实现了这一点 尽管 CSS 属于（或应该属于）设计人员关注的范畴 它率先提出了关注点分离原则 几乎每个开发人员都对此非常敏感 因此 CSS 很快获得采用 它在 Web 开发过程中如此根深蒂固 以致于有时难于满足最新网站的需求

　问题并不是 CSS 不足以满足样式最新 图形丰富并且外观吸引人的网站需求 而是纯粹的声明语言并非始终适合表现复杂的互联样式声明 好在只要编写正确 CSS 对于浏览器仍然合理 但对人来说也是如此吗？

　Web 开发中一个相对较新的方向是围绕 CSS 构建基础结构 使开发人员和设计人员能够以可持续性更高的方式生成相同的 CSS 最终的浏览器样式表并无变化 但其生成方式应有所不同 更易读也更容易管理

　这一 Web 开发领域出现于几年前 现在日渐成熟 有几个可用的框架可以帮助您进行动态 CSS 内容生成 我将提供其中一个框架 也就是 LESS Framework 的执行概要 并演示它如何与 ASP NET MVC 解决方案集成

为何采用 LESS？

　开发人员借助 LESS 解决的最大问题之一 是信息的重复 作为软件开发人员 您可能了解 切勿重复 (DRY) 原则并且每天都在应用 DRY 的主要优点在于 它减少了相同信息的存储位置 因而减少了应更新该信息的位置的数量

　对于普通 CSS 您根本不会遇到 DRY 问题 例如 在某些其他情况下 如果多个类中使用某种颜色 而您需要对其进行更改 可能除了逐一更新之外没有更好的办法了 使用 CSS 类可以定义特定元素的外观 并针对样式相关的元素以相同的方式跨页面重复使用 尽管 CSS 类确实可以减少重复 但有时在其他方面显得不足

　CSS 类的一个问题是它们在语义 HTML 元素的级别运行 在构建各种 CSS 类时 经常需要重复颜色或宽度等细节信息 对这些可重复细节中的每一个使用同一个类并不方便 即使设法用一个 CSS 类表示几乎所有可重复样式 如颜色和宽度 当开始对语义元素（如容器）应用样式时 还是应该连用多个 CSS 类以便实现所需的效果

　如果您曾用 Bootstrap 等框架设计过网页 就会明白我的意思 例如

　<a class= btn btn primary />

　首先将锚点设置为一个按钮（类 btn） 然后设置为特定风格的按钮（类 btn primary） 这种方法有效 但可能需要进行大量工作提前计划所需的类 这会增加 Web 项目的工作量 而项目往往时间紧迫

　LESS 这样的动态样式表语言表示一种横向思维 您不必花时间尝试使普通 CSS 变得更加智能 只需使用不同的工具（一般是语言）进行生成即可 因此 LESS 是一种框架 它向 CSS 编码添加了编程人员友好的概念 如变量 块和函数

　与动态 CSS 生成严格相关的 是将其处理为普通 CSS 供浏览器使用的问题 客户端可以通过临时 JavaScript 代码处理 LESS 代码 也可以在服务器上对其进行预处理 使浏览器只接收最终的 CSS

在 ASP NET MVC 中设置 LESS

　我将演示从 ASP NET MVC 应用程序中使用 LESS 所需的操作 首先 我将重点介绍 LESS 代码的客户端处理 在布局文件的 HEAD 部分添加以下内容

　<link rel= stylesheet/less type= text/css href= @Url Content( ~/content/less/mysite less ) /> <script type= text/javascript src= @Url Content( ~/content/scripts/less min js ) ></script>

　这里假设您已在项目中创建了 Content/Less 文件夹以包含所有 LESS 文件 您需要一个 JavaScript 文件 以便在浏览器中进行实际的 LESS 到 CSS 处理 您可以从 获取该脚本文件 我将回顾一些可证明 LESS 有用的场景

　

运行中的 LESS 变量

　观察 CSS 渐变是了解 LESS 变量作用的好方法 多年以来 设计人员使用小的 GIF 文件绘制 HTML 容器的渐变背景 最近 浏览器增加了 CSS 渐变支持 这也是官方 CSS 标准的一部分 通过线性渐变语法及其变体实现 很遗憾 如果要确保尽量多的浏览器采用这种渐变 必须借助一些东西 如 图 中的代码

　 图 中的代码几乎不可读 更糟的是 在需要渐变的任何地方都必须重复使用这些代码 此外 如果要稍微更改一下渐变颜色（或只更改饱和度或淡化效果） 唯一的办法是在所有位置进行手动编辑 直截了当地说 这非常困难 但是 这是对于普通 CSS 唯一可行的方法

　 图 在多种浏览器中显示渐变的综合代码

　

　/ Old browsers fallback / background color: #ff ; background: url(images/red_gradient png); background repeat: repeat x; / Browser specific syntax / background: moz linear gradient( left #fceabb % #fccd d % #f b % #fbdf %); background: Webkit linear gradient( left #fceabb % #fccd d % #f b % #fbdf %); background: o linear gradient( left #fceabb % #fccd d % #f b % #fbdf %); background: ms linear gradient( left #fceabb % #fccd d % #f b % #fbdf %); / Standard syntax / background: linear gradient( to right #fceabb % #fccd d % #f b % #fbdf %);

　为找到更好的解决方案 您需要跳出 CSS 试试 LESS 在 LESS 中 您只需定义一次渐变 CSS 然后在适当的位置按名称引用即可 例如

　 background gradient orange { background: #fceabb;              }   &ntainer { background gradient orange; }            

　名为 background gradient orange 的类按名称在适当的位置嵌入到类容器和任意其他类中 而渐变定义保存在一个位置

　从开发人员的角度来看 这并不是什么革命性的改变 不过 它使用了变量功能 这是 CSS 中没有的 事实上 如果将文件保存为普通样式表并引用的话 前面的语法并不可行 需要一些代码将扩展语法转换为普通 CSS 这正是 LESS JavaScript 分析器的功能 它将变量扩展为其实际 CSS 内容

　变量还适用于颜色或大小等标量值 请考虑以下 LESS 代码

　@black: # ;    #main {  color: @black; }     header { background color: @black; }            

　分析器将 @black 变量扩展为分配的值并进行全文件替换 最终效果是 在一处更改实际颜色 整个文件中的相应内容会自动更改 运行中的 LESS Imports

　如果需要 您可以将 LESS 代码拆分到多个文件 引用文件和包含的类中 例如 假设您创建一个 gradients less 文件 内容如下

　 background gradient orange { background: #fceabb;              }            

　在另一个 LESS 文件中 如 main less 您可以通过导入该文件引用任何渐变

　@import "gradients";   &ntainer { background gradient orange; }            

　如果 gradients less（扩展名不是严格必需的）位于其他文件夹中 则应在调用中指示路径信息以便导入 LESS Mixin

　我调用该 LESS 项目进行变量渐变 严格来说 这并不完全正确 在 LESS 中 一个变量包含一个单一值 一个 CSS 类容器被称为一个 mixin 这类似于函数 但不包含任何自定义逻辑 就像函数一样 LESS 可以接受和处理参数 请看看图 中演示 mixin 的代码

　在图 中 一个名为 shadow 的 mixin 定义了框阴影样式 并将颜色作为外部参数公开 与之类似 text box mixin 定义输入字段的基本外观 它导入阴影定义并保持宽度为参数化形式 通过这种方式 为不同大小（mini normal 和 large）的输入字段定义三个类就非常简单了 更重要的是 它只需进行少量编辑工作 更新也非常简单（请参阅图 ）

　图 LESS Framework 中的 Mixin

　/  Mixins  /     shadow(@color) {      box shadow: px px px @color;    }     text box(@width) {       shadow(# );      border: solid px # ;      background color: #dddd ;      padding: px;      width: @width;    }    /  CSS classes  /     text box mini {       text box( px);    }     text box normal {       text box( px);    }     text box large {       text box( px);    }

　 图 运行中的 LESS Mixin

　Mixin 可以接受多个参数或可变数量的参数 此外 每个参数都支持默认值

　 mixin(@color: #ff ) {              }            

　LESS 并不是富编程语言表示 它的设计缺少命令来指示条件或循环 但 mixin 的行为仍然可以根据所传递的值发生变化 假设您要对一个较大的按钮使用较粗的边框和字体 您定义一个名为 button 的参数化 mixin 使用关键字 when 将设置与条件绑定 条件必须基于一个参数

　 button (@size) when (@size < px) {     padding: px;     font size: em;     width: @size ;    }     button (@size) when (@size >= px) {      padding: px;      font size: em;      font weight: ;      background color: red;      width: @size ;    }            

　您应用不同的设置 但也可以使用基本操作通过一个系数将大小扩大为数倍 然后在实际 CSS 类中使用 mixin

　 push button large {       button( px);    }     push button all {       button( px);    }            

　运行此代码的结果如 图 所示

　 图 在 CSS 类中使用 LESS Mixin 的效果

　LESS 附带很多可操作颜色的预定义函数 您可以使用函数按百分比调整颜色亮度和饱和度 也可以按百分比设置颜色淡入和淡出 如下所示

　 push button {      background color: fade(red %);    }            

　有关 LESS 支持的函数的完整文档 请参阅 嵌套类

　我个人觉得需要重复 CSS 块指示同级样式非常讨厌 下面是一个典型示例

　#container h {              }    #container p {              }    #container p a {              }    #container img {              }            

　在编写得很好的普通 CSS 中 实际上可以避免很多重复 但使用平面列表布局样式的方式并不是最好的 在这种情况下 最好使用一些层次结构 在 LESS 中 可以像这样嵌套样式规则

　&ntainer {      h {        font size: em;       color: fade(# %);       a {         color: # ;         &:hover {color: red;}        }      }    }            

　经过处理后 前面的 LESS 代码会产生下面的样式

　&ntainer h   &ntainer h a   &ntainer h a:hover            

　服务器端处理

　您可以原样下载 LESS 代码 在客户端通过 JavaScript 代码对其进行处理 也可以在服务器上进行预处理 然后将它作为普通 CSS 下载到客户端 在前一种情况下 完全像使用普通 CSS 文件一样 服务器端更改在下一次页面刷新时应用到客户端

　如果您注重性能 处理的是大型复杂 CSS 文件 则服务器端预处理可能是更好的选择 服务器端预处理发生在您每次修改服务器上的 CSS 时 您可以在生成过程结束时手动完成额外的步骤 使用 LESS 编译器从命令行将 LESS 代码预处理为 CSS 此编译器是为服务器端工作安装的 less NuGet 软件包的一部分

　不过 在 ASP NET MVC 中 可以将 LESS Framework 与捆绑机制集成 有关捆绑机制 请参阅我在 年 月的专栏 CSS 编程 捆绑和缩小 (msd/magazine/dn ) 这确保只要请求 LESS 文件 就会执行 LESS 到 CSS 的转换 还确保通过 If Modified Since 标头正确管理缓存 最后 您可以将分析和缩小混合起来 要在 ASP NET MVC 中集成 LESS 首先需要下载并安装 less NuGet 软件包 然后将以下代码添加到 BundleConfig 类

　var lessBundle =      new Bundle("~/myless") IncludeDirectory("~/content/less" " less");    lessBundle Transforms Add(new LessTransform());    lessBundle Transforms Add(new CssMinify());    bundles Add(lessBundle);            

　捆绑将打包在指定文件夹中找到的所有 less 文件 LessTransform 类负责 LESS 到 CSS 的转换 该类使用 less API 分析 LESS 脚本 LessTransform 的代码非常简单

　public class LessTransform : IBundleTransform    {      public void Process(BundleContext context BundleResponse response)      {        response Content = dotless Core Less Parse(response Content);        response ContentType = "text/css";      }    }            

　更多智能工具

lishixinzhi/Article/program/Web/201404/30643

ORA-03134: 不再支持连接到此版本的服务器。

ORA-03134: Connections to this server version are no longer supported

Cause: An attempt was made to connect to an Oracle server of older version

Action: Please refer to documentation for more details

------------------------------------------------------

8i必须是把补丁打到8174

select from v$version;

-------------------------------------------------------

10g的支持817以上版本！

11g就只支持9i以上版本了！

不太明白你的意思。

1种方式是SingleR的方式。这种方式的原理是 客服端每次请求都会创建一个GuID连接唯一吗，根据这个就能知道是哪个客服端了，用Nuget下载一个包就可以了

你在程序包管理控制台可输入install-package MicrosoftAspNetSignalR 也可以安装，然后去官方看文档

2你说的根据IP的方式我给你一个获取IP的方法。

public static string

IPAddressAll

{

get

{

string

ip =

HttpContextCurrentRequestUserHostAddress;

string

agentip =

HttpContextCurrentRequestServerVariables["HTTP_X_FORWARDED_FOR"];

if

(!stringIsNullOrEmpty(agentip))

{

//有代理

if (agentipIndexOf("") ==

-1)

agentip =

null;

if (agentip != null)

{

if

(agentipIndexOf("unknow") != -1)

agentip =

agentipReplace("unknow", stringEmpty);

string[]

temparyip = agentipReplace("

", stringEmpty)Replace("'",

stringEmpty)Split(new char[] {

',', ';' });

//过滤代理格式中的非IP和内网IP

for (int

i = 0; i <

temparyipLength; i++)

{

if (temparyip != stringEmpty

&& IsIPAddress(temparyip)

&& temparyipSubstring(0,

3) != "10"

&& temparyipSubstring(0,

7) != "192168"

&& temparyipSubstring(0,

7) != "17216")

{

ip += "," +

temparyip;

}

}

}

}

else

{

agentip

= null;

}

return ip;

}

}