作为 .NET 开发者，你是否经常需要查找命令行指令？本文为你整理了开发过程中最常用的 dotnet 命令，涵盖项目创建、构建、测试、部署等多个方面，助你提升开发效率！
重要的操作命令一些常用的命名
创建并添加项目到解决方案1234567891011# 创建 Web API 项目dotnet new webapi -o MyWebApi# 创建空解决方案dotnet new sln -o MySolution# 进入解决方案目录cd MySolution# 将 Web API 项目添加到解决方案中dotnet sln add ../MyWebApi/MyWebApi.csproj
发布为独立部署应用（带运行时）12# 发布 Web API 项目，配置为 Release，平台为 win-x64，且自带运行时dotnet publish ../MyWebApi/MyWebApi.csproj -c Release -r win-x64 --self-contained
查看 SDK 和运行时信息12345# 查看所有已安装的 .NET SDK 版本dotnet --list-sdks ...
今天我们不学习，来聊一聊MCP服务的未来。通过前面几期的学习，我们知道使用MCP服务有两种方式。
一、stdio方式，即服务端和客户端在本地一起。
优点：
1.可以利用现有的助手类工具，如Cursor，VSC+插件，或者最近开源并快速发展的DeepChat。通过搜寻开源的MCP服务，如高德MCP，CloudFlare MCP等。
2.可以使用对本机操作的MCP服务。
缺点：
1.只能1:1绑定客户端，每个客户端都要重新安装配置一遍。
2.因需要本地运行，依赖本机的运行环境。
二、sse方式，即服务端和客户端逻辑分开，可以不在一台机器上。
优点：
1.可以在组织内共享服务，真正的服务运行在远端服务器上。
2.降低助手类工具使用门槛。
缺点：
1.增加服务端运维的复杂性。
2.无法对使用者本地机器进行控制。
不同的使用场景，需要使用不同的方式。同时，即使确定某种方式，也还存在落地上的问题。因此为了更好的解决实现和使用上的问题，MCP继续完善协议(大家都有活干了)。我们来看看官方的规划吧！
**01.**H1Roadmap1.Remote MCP Support
目前主流的工具 ...
今天我们将继续学习，将了解MCP服务的SSE通信的客户端编写。当完成之后，就可以连接上节课的SSE服务了。
等系列课学习完成，你将能了解什么是MCP，如何开发MCP和如何实际使用它（当然我们会回归到Dify中，配合LLM，更加完善我们的AI应用适用场景）。
**01.**动手做一做我们再来复习一下协议的架构。
我们看到Client和Server之间是MCP Protocol通讯的，但是我们已经用了两篇文章来解释服务端开发，显然他们一个是stdio，另一个是SSE，是不一样的。
因此，Client必然是有差异的，今天我们就来看看如何实现目标。
同样从TypeScript的SDK开始，来写一个Client(SSE通信方式)。
在目录下新建一个client.ts文件，引用SDK的client和sse，其余代码见下图。
代码不多，仅作演示。谜题揭晓，SSE的服务需要用SSEClientTransport去连接。而本地stdio服务，就需要用StdioServerTransport去连接。目前大部分助手类工具都是用的stdio的方式。这里卖个关子，在Dify应用中，会讲如何更好的使用MCP。 ...
今天我们将继续学习，将了解MCP服务的另一种通信方式。当然这两种都是有不同的适用场景的，并非竞争的关系。后面也会说明，其各自的优缺点和场景。
等系列课学习完成，你将能了解什么是MCP，如何开发MCP和如何实际使用它（当然我们会回归到Dify中，配合LLM，更加完善我们的AI应用适用场景）。
**01.**动手准备在我们动手写一个自己的SSE版本的MCP之前，又需要了解协议的一些概念，这样做起来就得心应手了。
Resoures：暴露结构化数据的内容给LLM。
Prompts：提供给LLM应用的可重用Prompt模板。
Tools：提供在服务端给LLM应用特别是Agent使用的工具。
Roots：定义API的接入点和访问路径
Sampling：允许服务器通过客户端请求LLM完成
当然以上不是全部都必须，比如可以只实现Tools功能，那我们同样从TypeScript的SDK开始。
上一课的例子是通过stdio传输数据，即数据是本地机器的进程间通信。适合AI助手工具来软件使用。
而今天我们来尝试实现远程通信。
**02.**动手做一做复制一下上节课的项目，做以下修改：
1234 ...
今天我们将继续学习，基于model context protocol的SDK来开发自己的MCP服务。
等系列课学习完成，你将能了解什么是MCP，如何开发MCP和如何实际使用它（当然我们会回归到Dify中，配合LLM，更加完善我们的AI应用适用场景）。
**01.**动手准备今天就来展开说说开发MCP应用，应该如何做。既然是开发，那就离不开代码了。处理的顺序正好和概念反过来，我们先来实现一个MCP服务端。
同时需要理解两个重要的概念：
1 通信机制MCP协议支持两种主要的通信机制：基于标准输入输出的本地通信和基于SSE(Server-Sent Events)的远程通信。
也就是说MCP服务端，根据和客户端连接时所在的位置不同，分成本地通信和远程通信。
本地通信是通过stdio传输数据，即数据是本地机器的进程间通信。适合AI助手工具等软件使用。
而远程通信则是利用SSE技术，通过HTTP来通信和传输数据。适合于共享MCP服务，在企业内使用或者服务给互联网用户。
2 运行语言和环境一般涉及到开发，必定是要和开发语言有关。但是MCP协议是和语言无关的，也就是说大家可以尽量使用自己熟悉的开发语言 ...
上一节Dify应用实战课，我们学习了如何将数据表生成图，可以更直接的展示数据的意义。
今天我们将暂时将Dify的学习搁置一下。来学习AI工具中重要的一个知识：MCP(Model Context Protocol)。
等系列课学习完成，你将能了解什么是MCP，如何开发MCP和如何实际使用它（当然我们会回归到Dify中，配合LLM，更加完善我们的AI应用适用场景）。
**01.**基础概念MCP(Model Context Protocol)是一种开放协议，它标准化了应用程序如何为LLM提供上下文。
将MCP想象成AI应用程序的USB-C端口。正如USB-C提供了一种将设备连接到各种外围设备和配件的标准化方式一样，MCP也提供了一种将AI模型连接到不同数据源和工具的标准化方式。
它是去年11月才被Claude公司提出来的，但是不到半年时间，基于MCP的生态就如雨后春笋般涌现。过去以API方式提供服务的传统互联网，迅速拥抱这一变化，大量的MCP服务被开发，开源和提供出来。
要想开发MCP应用，首先需要了解的是其架构和几个重要的概念。
简单的图示中，提到了主机，客户端和服务器。
1 主机MC ...
最近还是有网友问，代码执行节点为啥运行报错，说找不到模块。但自己的Python环境是安装了这些模块的。还有就是按照麦金叔的数据库连接，为啥连不上。今天我们再详细说说。
**01.**库和权限 当你运行代码节点出现如下两种错误的时候，这一篇就是为你准备的。
最简单的方式就是在Dify的沙箱环境进行依赖库的安装和权限设置。
库安装：
工程目录下docker/volumes/sandbox/dependencies下有一个空文件python-requirements.txt，打开文件后
增加一行”pandas==2.2.3”，如果你代码使用了其他第三方库，也像正常pip install或者conda install一样，将使用的库，依次添加即可。
权限修改：
工程目录下docker/volumes/sandbox/conf里面有一个config.yaml文件，找到allowed_syscalls段，把需要的权限加进去。
还是有同学不知道怎么操作，也有不放心权限太大的，麦金叔把所有的code和解释都放这 ...
**01.**动手做一做随便创建一个工作流。添加”代码执行”和”结束”。
并填入代码如下：
保存后进行测试。结果如下图：
提示非常清楚，就是找不到依赖库pandas。
那我们就把库安装上，因为运行时是由sandbox提供的，所以我们找到docker-compose.yaml中sandbox的定义。其中有个卷的映射，
./volumes/sandbox/dependencies:/dependencies
这里就是我们添加依赖的地方。工程目录下docker/volumes/sandbox/dependencies下有一个空文件python-requirements.txt
输入一行"pandas==2.2.3"
重启docker服务，查看docker-sandbox-1的日志，会看到在启动sandbox时，会安装第三方库。
重新运行”工作流”(如果还报错找不到pandas，需要等待一会儿，安装有可能还没有完成，一定要看到sandbox的log里面显示python dependencies installed)。发现已经不再报错找不到pandas，而是提 ...
这两天有网友问，上次的课提到了数据库查询，对一般的人还是有点难度。所以希望大模型也能生成SQL，可以自己去查询数据库的数据。
麦金叔建议他使用文生SQL的模型，网友应该真的去尝试了，只不过还是有问题。那今天麦金叔就来演示一下，如何处理这一需求，并解决查询报错的问题。
**01.**动手做一做今天的任务专题是解决让大模型生成SQL查询语句，并利用数据库工具查询得到结果。
依然用工作流作为测试。添加下图所示节点，依次为”开始”，”LLM”，”参数提取器”，”SQL EXECUTE”和”结束”。
将”开始”节点，添加一个参数”user_promt”。这样在对话时，可以将查询要求填入。
“LLM”节点选择模型为”qwen2.5-72b-instruct”，上下文选择”开始”节点新增的参数”user_promt”，将系统提示词按如下填入：
请直接提供答案，无需解释思考过程。
根据用户输入 上下文
进行SQL的生成，最终结果仅包含SQL语句。
数据库的schema如下：
12345678910111213141516171819CREATE TABLE `doctor` ( `id` int ...
今天我们将要继续企业应用之旅，让Dify自己也变成为MCP服务，成为助手类工具或者现有系统的定制化AI工具服务。
学习完成，你将能让自己的桌面助手工具，集成最近一段时间辛苦创建的Dify应用。这样就可以暂时不去Dify的控制台去使用工作流了。
**01.**准备环节在我们开始之前，有需要安装一个工具。感谢伟大的开源作者们的奉献，这个世界因你们而精彩。
去插件->marketplace，搜一下SSE，看到下图这个插件，就安装一下。
至此，所有今天需要的准备就完成了，恭喜！
**02.**动手做一做找到之前实战的案例：”图片生成”，简单裁剪一下。然后去发布那里，发布为工具。
按照下图所示，输入一个工具调用名称，并且描述写好，最好详细一点，能让大模型理解这个工具到底是干啥的。
此时在Dif有点工作流里，应该就出现这个应用了。
接着开始配置新安装的插件。
进入插件，找到它”MCP Compatible Dify Tools”，点击之后，会出现在页面右边。这时继续点击”API端点”右侧的加号。
就会进入端点配置页。填入端点名称，可以随意输入。然后点击”工具列表”右侧的加号。在弹出” ...
