dotnet restore [<ROOT>] [--configfile <FILE>] [--disable-parallel]
今天在少珺小伙伴的协助下,使用了 gitlab 的 runner 给全组的项目做自动的构建。为什么需要使用 Gitlab 的 Runner 做自动构建,原因是之前是用的是 Jenkins 而新建一个底层库项目想要接入自动构建等,需要来回在 Gitlab 和 Jenkins 上配置,大概步骤差不多有 20 步,同时还有一堆 Jenkins 的坑。另外服务器是共有的,有其他组的小伙伴安装了诡异的工具让我的打包不断炸掉。于是我就和头像大人商量使用虚拟机环境的方法,我在空闲的服务器上安装了 VirtualBox 虚拟机,然后在虚拟机部署 Runner 接着在项目接入,这样就可以确定打包的环境,同时迁移服务器也比较方便
如上,意思就是有两种解决方案,第一种,通过在项目中增加nuget.config文件,里边配一下源地址,哥们比较懒,不愿意去把所有项目都改一遍,于是就选用了第二种,在发布的时候加 -s参数指定包源
在 Nuget 中没有 -version 和 -v 和 --version 等写法,只需要直接输入 nuget 在第一行就会显示版本号
解决国内访问NuGet服务器速度不稳定的问题 ,这里推荐使用NuGet微软官方中国国内镜像
本文介绍如何添加自定义的 NuGet 源。包括全局所有项目生效的 NuGet 源和仅在某些特定项目中生效的 NuGet 源。
继阿里巴巴开源镜像站(https://opsx.alibaba.com/)、华为云镜像站点(https://mirrors.huaweicloud.com/ )之后,腾讯也已于近日上线了类似的服务,官方名称为腾讯云软件源(Tencent Open Source Mirror Site),为国内开发者提供新的软件镜像源选择[https://mp.weixin.qq.com/s/T43MZSDiN04EdgirBif1GQ]。与国内其他同类服务相似,此开源镜像站提供了主流的Linux发行版安装镜像下载以及软件源镜像,还有几大语言程序包的仓库服务,比如Node.js的npm仓库和Python的pip仓库以及dotnet的nuget 仓库。Nuget 镜像地址是(https://mirrors.cloud.tencent.com/nuget/)。
通过 NuGet 安装包时,NuGet 先将包下载至一个统一的目录,默认路径是:C:\Users\用户名\.nuget\packages
本文告诉大家如何移动 nuget 缓存文件夹。 因为 nuget 文件夹一般比较大,现在我的 nuget 文件夹有 10 G,默认的 nuget 文件夹是在C盘,所以需要移动他。
.NET CORE环境配置好了,跑hello world正常,引用TencentCloud .NET SDK里的TencentCloud\TencentCloud.csproj项目后,在编译的时候就有如下报错,甚至代码还是hello world都没改一个字也报这个错。
发布于 2020-01-03 09:41 更新于 2020-01-03 05:23
在项目中使用 NuGet 作为第三方类库管理器是非常方便的, NuGet 默认会在解决方案的目录下建立一个名为 packages 的目录, 把解决方案所需的第三方类库都放到 packages 目录下, 解决方案下所有的项目都引用 packages 目录内的类库, 对于单个解决方案来说, 非常不错。
在下面的博客正文中,都假设我的本机搭设了代理服务,其中 SOCKS5 代理服务的端口号是 7777,HTTP 代理服务的端口号是 7778。
一、本地dll如何打包,以及版本的更新 本小节主要介绍两种方式将本地dll打包为Nuget包, 1.1 利用nuget.exe进行打包(应用于.net framework) 1. 下载nuget.ex
我在开发的时候需要使用到一些 DEBUG 库进行调试,但是我的库是通过 NuGet 给用户的,如果在 NuGet 里面使用到了 DEBUG 的库那么会让代码的运行效率降低。于是我就找到一个方法,可以在 NuGet 同时打包调试和发布的包,这样在用户调试的时候就可以使用调试的代码
本地构建能通过至少代码上的问题不大,本文列举了一些可能的原因,小伙伴可以按照顺序依次查看代码和配置
现在,在档期按目录下面生成了一个叫Google.Grpc.1.20.0.nupkg的包
在.NET Core 1.0.0 RC2即将正式发布之际,我也应应景,针对RC2 Preview版本编写一个史上最简单的MVC应用。由于VS 2015目前尚不支持,VS Code的智能感知尚欠火候,所以我们直接采用最原始的记事本来编写这个MVC应用。[源代码从这里下载] 目录 步骤一、安装最新的.NET Core SDK 步骤二、定义源代码和配置 定义NuGet.xml 定义Project.json 定义入口程序 定义初始化类型
为了解决上述问题,从17.05版本开始Docker在构建镜像时增加了新特性:多阶段构建(multi-stage builds),将构建过程分为多个阶段,每个阶段都可以指定一个基础镜像,这样在一个Dockerfile就能将多个镜像的特性同时用到,例如:先用SDK镜像构建.NET Core工程,再把构建结果和Runtime 合成,就做成了一个可以直接运行.NET Core工程镜像了;
最近入职了一家新公司,公司各个方面都让我非常的满意,我也怀着紧张与兴奋的心情入职后,在第一天接到了领导给我的第一个任务——把整个项目的依赖引用重新整理并实施项目的CI/CD。
nuget的包源无法访问(无法ping通),而我在一台服务器上访问https://api.nuget.org/v3/index.json时则会自动重定向到https://nuget.cdn.azure.cn/v3/index.json。
C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config
创建数据挂载目录并赋予权限:以 UID 200 的形式运行 mkdir ./data && chown -R 200 ./data
有一些项目需要使用一些特殊的 Nuget 才可以下载,但是不能在开源的项目需要小伙伴下载仓库在自己的 VisualStudio 修改自己的 Nuget 链接才能编译,本文告诉大家将某个项目独立的 Nuget 配置放在一个文件
2、Notice: NuGet Restore Failures on Linux distributions using NSS or ca-certificates #10712 :https://github.com/NuGet/Home/issues/10712
当容器终止时,容器引擎使用退出码来报告容器终止的原因。如果您是 Kubernetes 用户,容器故障是 pod 异常最常见的原因之一,了解容器退出码可以帮助您在排查时找到 pod 故障的根本原因。
默认情况下所有的Nuget包都会下载到C盘,目前我这边有几十个G的大小,这导致我C盘的容量越来越小…
在分析 DUMP 进行自动化调试的时候,很多时候只能通过 WinDbg 和命令行调用的方式,这样的方式很难做到灵活。同时编写各个命令行的难度也特别高,这在需要对命令行的输出进行不同的分支的判断时候,难度会更大。于是找到了 Microsoft.Diagnostics.Runtime 库,这个库提供了简单的方式,可以在 C# 里面用代码写分析 DUMP 的代码
上次我们讲到过如何在ASP.NET Core中使用WebSocket,没有阅读过的朋友请参考 WebSocket in ASP.NET Core 文章 。这次的主角是SignalR它为我们提供了简化操作WebSocket的框架。
前几天微软收购npm的新闻对于软粉来收很是振奋。微软收购npm很可能是为了加强Github Packages。目前Github,Typescript,VSCode,npm这些开源社区的重磅工具全部都在微软旗下,显示出了微软对开源的态度,微软已经不是以前那个封闭的微软。Github推出Github Packages功能有一段时间了,一直没使用过,今天有空打算折腾一下,体验一下。
今天我们分析了博客站点的2次故障(故障一、故障二),发现一个巧合的地方,.NET 5.0 正式版的 docker 镜像是在11月10日提前发布上线的。
Visual Studio中对项目所做的配置,均可在该文件中体现出来。同样,Visual Studio也是根据该文件中的内容来加载项目的。抛开Visual Studio的其它功能,可以将其看作是.csproj文件的图形管理工具。
在微软的 Build 2021 大会上,微软发布了 .NET 6 Preview 4,同时发布了于它的 MAUI 第四个预览版。在 MAUI 成为 Visual Studio 2022 的官方工作负载之前,成功编译并运行 MAUI 的示例程序会比较麻烦,本文旨在帮助大家完成示例程序的编译运行和体验。
在 Docker Entry Script 详解中介绍了如何在 shell 脚本中响应 Unix 信号量来实现 Docker 应用优雅的关闭退出, 本文介绍 C# 程序如何在 Docker 中响应 Unix 信号实现优雅的关闭退出。
这样是 或 的关系, 只要满足 branches 为 main 或者 tags 为 PluginCore-v* 就会触发
龙芯平台.NET,是龙芯公司基于开源社区.NET独立研发适配的龙芯版本,我们会长期进行安全更新和错误修复,并持续进行性能优化。社区.NET7版本开始已经原生支持LoongArch64架构源码。具备如下特性:
上次讲SignalR还是在《在ASP.NET Core下使用SignalR技术》文章中提到,ASP.NET Core 1.x.x 版本发布中并没有包含SignalR技术和开发计划中。时间过得很快,MS已经发布了.NET Core 2.0 Preview 2 预览版,距离正式版已经不远了,上文中也提到过在ASP.NET Core 2.0中的SignalR将做为重要的组件与MVC等框架一起发布。它的开发团队也兑现了承诺,使用TypeScript对它的javascript客户端进行重写,服务端方面也会贴近ASP.NET Core的开发方式,比如会集成到ASP.NET Core依赖注入框架中。
本文来告诉大家如何根据 基线包版本 的功能来实现自动在构建过程中,告诉开发者,当前版本是否存在不兼容旧版本的变更。其不兼容变更包括二进制中断变更和 API 不兼容变更和源代码中断变更。可以让库开发者花更少的精力在测试兼容性上
在软件工程不少的思想、概念来源于建筑工程,大家也喜欢把开发软件比喻成建房子。那么如果说运维是软件的地基,那么框架就是承重墙。起房子就是先打地基,再建承重墙。地基打得越稳,房子才能起得更高。也等同于运维技术越扎实,系统才能更加健壮。
注:同一仓库源可以有多个 TAG,代表这个仓库源的不同个版本,我们使用 REPOSITORY:TAG 来定义不同的镜像。如果你不指定一个镜像的版本标签,例如你只使用 ubuntu,docker 将默认使用 ubuntu:latest 镜像。
我有一个 NuGet 库有新的版本,但是我的服务器速度不够快,此时我第一次使用 NuGet 还原找不到库。在我服务器索引完成之后,再次使用 NuGet 会依然找不到这个库,而此时服务器准备完成。这是 NuGet 的缓存的坑
首先出现这个bug的是在我的vs2017社区版的ide上,这两天使用了出现了一个非常神奇的问题,就是我程序中的nuget包总提示找不到源文件,并且我点击Nuget还原的话还一直提示着一个问题。
在使用 ASP.NET Core 的 docker 调试的时候,在生成的这一步提示 C:\Program Files\dotnet\sdk\3.1.201\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(424,5): error MSB4018: “CreateAppHost”任务意外失败 可能的原因是 docker 内之前的容器没有关闭
首先进入到ES容器中, 然后进入到指定目录修改elasticsearch.yml文件
centos 启动一个容器添加了-d 参数,但是docker ps 找不到容器,docker ps -a查看却已经退出了 [root@VM_0_6_centos ~]# docker run -d centos a44b2b88559b68a2221c9574490a0e708bff49d88ca21f9e59d3eb245c7c0547 [root@VM_0_6_centos ~]# docker ps 找不到容器信息 [root@VM_0_6_centos ~]# docker ps -a status列显示已退出 [root@VM_0_6_centos ~]# docker logs centos 没有任何异常日志
在上一篇博客告诉小伙伴如何使用 github 做持续集成,本文告诉大家如何配置 github 让在 master 每次合并都会自动创建一个 nuget 文件,自动上传
领取专属 10元无门槛券
手把手带您无忧上云