企业官网建设流程全解析

简介：这是一份基于C#与Winform框架开发的仓库管理系统完整源码，搭配SQL Server数据库脚本及数据文件，面向初中级.NET桌面应用开发者与需要快速搭建库存管理系统的项目人员。系统覆盖入库、出库、采购、退货、库存盘点及用户权限等核心业务模块，通过多个业务窗体与数据交互形成闭环管理流程，适用于课程设计、毕业设计或企业内部系统二次开发。压缩包内共113个文件，包括37个cs逻辑代码、33个resx界面资源、16个resources资源文件，并附有sql脚本与mdf/ldf数据库文件，另有sln解决方案文件便于直接打开调试，整体仅679KB，结构清晰、便于移植。资源已获得425人学习关注，适合希望从实际项目中掌握Winform事件驱动、数据库连接与仓储业务建模的读者。

1. 这套 C# WinForms 仓库管理系统源码+数据库：拿到手第一步先别急着编译

标题里的“winfom”是 winform 的笔误，你按两个拼法去检索都能找到同类项目。这种源码包在课程设计和外包项目里出现频率极高：VS2015 里打开就能编，配一个 SQL Server 数据库，跑起来就是一套能录商品、开入库单、给出库单、查库存的桌面系统；数据库文件夹里一般放着 .bak 备份或 .sql 脚本，所谓“源码+数据库”指的就是这两部分。它适合三类人——要交课程设计的学生、想给自家小仓库配一套内网工具的新手工程师，以及打算在这套骨架上做二次开发的团队。我先把整套系统的结构、数据库设计、运行方式和常见坑讲清楚，再带你把它跑起来，最后改造成自己的业务。如果你第一次碰这类系统，请务必按章往下读，而不是直接双击 .sln。

2. 先看懂架构再动手：WinForms 仓库系统的功能地图与数据库设计

2.1 功能模块地图：登录、基础资料、单据与库存查询

打开这类源码，项目结构大同小异。一个解决方案底下通常有两到三个项目：一个主程序（WinForms 的 .exe），可能还有一个公共类库；偶尔有单独的数据库脚本文件夹。主程序里按窗体划分功能，最常见的布局是——登录窗体（LoginForm）负责验证账号密码，验证通过后打开主窗体（MainForm）。

主窗体通常用 MenuStrip 做一级菜单，左边可能挂着一个 TreeView 或 Panel 放按钮，右侧是 DataGridView 展示数据。功能模块基本可以摊成一张表：

这张表不是让你背的，而是让你拿到源码后先去对一对：这个包有没有缺模块。有些精简版只有商品和入库，没有出库；有些把供应商、客户也砍了。你在选型阶段就要有数，否则吭哧吭哧跑通了才发现要补一张表，返工量很大。

桌面端做这种系统最大的优势是开发路径短。VS2015 里拖控件、双击控件写事件、往 SqlConnection 里拼 SQL，三天就能出第一版。相比网页端要搞 IIS 或 Nginx、要处理跨域，WinForms 在局域网里就是零部署——把编译好的 exe 拷到每台电脑上，能连数据库就能用。这也是仓库这种固定岗位、固定内网设备的场景至今仍在用它的原因。你拿到源码后，先不要纠结界面丑不丑，先把模块地图和数据库对上，这一步决定了后面改动的工作量。

2.2 单据主表与明细表：一套不入坑的字段设计长什么样

打开数据库脚本，表名五花八门，但核心不会逃出这三类：基础资料表、单据表、库存表。基础资料表好理解：用户表、商品表、分类表。单据表往往是成对出现的——t_InStock 是入库单主表，t_InStockDetail 是入库明细。主表记录一张单据的公共信息：单号、供应商、经手人、入库日期；明细表记录这张单里每一行商品的编号、数量、单价。两张表靠 BillId 或 InStockId 关联。

为什么要拆？因为一张入库单包含多种商品。如果只建一张表，要么把多个商品塞进一个字段（这种设计是灾难），要么把公共信息重复写多行（统计和改单都很麻烦）。拆成主表+明细后，改单就是先删明细再重插明细，公共信息只维护一次。下面这套字段基本能对应 90% 的教学版源码：

库存表的设计是最容易踩坑的地方。很多教学版源码里 t_Stock 就是一张快照表：ProductId 加 Qty，入库时 UPDATE 加数量，出库时 UPDATE 减数量，查询直接 SELECT。这种设计简单，能跑通课程设计，但它有两个硬伤：一是不记录流水，无法回答“这个月入了多少、出了多少”；二是并发一高，两条线程同时改同一行库存，容易覆盖更新。真正的工业版至少再加一张流水表，用单据驱动库存变动。你拿到源码后先看它是哪种，心里有个数——如果是快照版，加流水表可以作为你二次开发的第一个练手点。

2.3 事件驱动与数据绑定：WinForms 桌面程序到底怎么跑

理解 WinForms 程序的运行逻辑，才能改得动。它和网页不同，没有路由和 MVC，核心是事件驱动：你在表单上拖一个按钮，双击它，VS 自动生成了 button1_Click 方法，程序等待用户操作，点了就执行这个回调。你改的大部分业务代码，都发生在这类方法里。

数据展示环节，最常用的套路是 ADO.NET 的固定四件套：SqlConnection 开连接、SqlCommand 执行 SQL、SqlDataAdapter 把结果填进 DataTable，再把 DataTable 直接赋给 DataGridView 的 DataSource。增删改查的全部秘密，就是围绕这几个类写 SQL。比如一个最简单的按钮事件：

private void btnQuery_Click(object sender, EventArgs e) { string sql = "SELECT ProductId, ProductName, Spec FROM t_Product"; using (SqlConnection conn = new SqlConnection(connStr)) using (SqlDataAdapter adapter = new SqlDataAdapter(sql, conn)) { DataTable dt = new DataTable(); adapter.Fill(dt); dataGridView1.DataSource = dt; } }

这里有几个参数层面的常识：SqlDataAdapter 的 Fill 会自己打开连接再关闭，不需要显式 Open；但如果你要执行 INSERT/UPDATE，就需要 SqlConnection 先 Open。connStr 这个字符串在哪定义、怎么改，下一章会专门讲。

这里还有个常见的理解误区：DataGridView 里直接删行、改单元格，只是改了界面上的数据，不会自动写回数据库。你必须把改动翻译成 UPDATE 或 DELETE 语句执行。很多新手以为“界面能编辑等于数据已经改了”，结果一刷新全没了。这个问题的标准解法在第 4 章，第 5 章也会再提一次。

3. 把源码跑通：数据库还原、连接字符串与首次编译全流程

3.1 环境准备：VS2015 还是 VS2019，目标框架怎么定

拿到源码先别急着双击 .sln，先看两个文件：解决方案下每个项目的 .csproj 里，有一行 TargetFrameworkVersion，写着 v4.0、v4.5 还是 v4.7.2。这一行决定了你用哪个 Visual Studio 版本。老课程设计大多是 v4.0 或 v4.5，VS2015 到 VS2019 都能打开；如果目标框架在 v4.7.2，那至少用 VS2017 或 VS2019。

我的建议是：本地没有 Visual Studio 的话，直接装 VS2019 社区版（免费），安装时勾选“.NET 桌面开发”工作负载。VS2015 老归老，但官方渠道难找，新系统上还容易缺组件。VS2019 打开旧项目会弹“框架升级”提示，选择不升级或升级到 4.7.2 都行，4.5 的项目在 Windows 10/11 上能直接跑。

数据库方面，这套系统用 SQL Server，Express 版和 Developer 版都够。要注意的是：老系统如果写死在 SQL Server 2008/2008R2 特性上，装 SQL Server 2019 也能兼容，但反过来高版本数据库文件装到低版本上会失败。建议直接装 SQL Server 2019 Developer，功能全、兼容性好。安装时记住实例名和 sa 密码，后面连接字符串要用。

3.2 还原数据库：先分清 .bak 和 .sql 两条路

打开数据库文件夹，你会遇到两种可能：一个 .bak 备份文件，或者一堆 .sql 脚本。路径不同，处理方式不同。

如果是 .bak 文件，用 SQL Server Management Studio（SSMS）还原是最直观的：右键“数据库”节点选“还原数据库”，源设备指向 .bak 文件，目标数据库名按源码文档或经验填。命令行做法是：

sqlcmd -S . -U sa -P 123456 -Q "RESTORE DATABASE CangKu FROM DISK='D:\db\CangKu.bak' WITH REPLACE"

如果备份文件里的逻辑文件名和现有数据库不一致，还原会报错。先用这条命令查逻辑名：

sqlcmd -S . -U sa -P 123456 -Q "RESTORE FILELISTONLY FROM DISK='D:\db\CangKu.bak'"

然后按查到的逻辑名写 MOVE 子句，加 REPLACE 覆盖同名数据库。还原完成后，进 SSMS 确认库里有哪些表，和 2.1 的功能模块对一下，确认没少表。

如果是 .sql 脚本，直接 SSMS 里打开执行。执行前先拉到文件开头看有没有 CREATE DATABASE。如果没有，就先手动建一个空库，再在目标库上下文里执行脚本。这一步最容易出错的是编码问题，中文乱码的坑在第 5 章展开。无论哪条路，还原完都建议执行一句 SELECT TOP 5 * FROM t_User，确认能读到数据再往下走。

3.3 改连接字符串：App.config 里的三处必改项

源码里所有连库逻辑，通常都从 App.config 读连接字符串。这个文件在项目根目录，编译后会自动变成 exe 同目录下的“程序名.exe.config”。典型内容如下：

<configuration> <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5"/> </startup> <connectionStrings> <add name="CangKuSystem" connectionString="Data Source=.;Initial Catalog=Warehouse;User Id=sa;Password=123456;MultipleActiveResultSets=true;Connect Timeout=5" providerName="System.Data.SqlClient"/> </connectionStrings> </configuration>

Data Source 是必改第一项。写“.”表示本机默认实例；如果你装的是 SQL Server Express，要写成“.\SQLEXPRESS”或“机器名\SQLEXPRESS”。User Id 和 Password 按你的 sa 账号改；如果你用的是 Windows 身份认证，把 User Id/Password 换成“Integrated Security=true”。Initial Catalog 是数据库名，要和还原出来的库名一致。

C# 代码里读它的方式几乎全是这一句：

using System.Configuration; string connStr = ConfigurationManager.ConnectionStrings["CangKuSystem"].ConnectionString;

注意两个坑：一是项目里如果有多个 .config 文件，改错了不生效；二是改完一定要重新生成，很多人改了根目录的 App.config 忘了编译，运行的是 bin 目录里的旧配置。判断当前程序用的哪个连接串，直接打开 bin 下生成的 .exe.config 看，和根目录文件对比一次就明白了。

3.4 首次编译与启动：从生成失败到看见登录窗

双击 .sln 进入 VS，先打开“视图→错误列表”，然后右键解决方案“重新生成”。老源码最常见的问题是 NuGet 引用丢失或 DLL 引用路径失效，错误列表里会出现红波浪。先把解决方案里的每个项目选成“启动项目”，登录窗体所在项目设为启动。

编译通过后按 F5，程序开始跑。如果弹异常，先看异常类型：SqlException 多半是连不上库；FileNotFoundException 多半是缺引用 DLL；FormatException 可能是配置文件里某个值类型不对。把异常第一行记下来，去网上搜原文，比瞎试快得多。

跑起来看到登录窗，用源码里写明的默认账号密码登录即可。如果源码文档没写，去数据库 t_User 表查一下，多数是 admin/123456 这类弱口令，或者临时给登录 SQL 加个 WHERE 条件改密码。看到主窗体的那一刻，这套系统的闭环就跑通了，后面的改造才有意义。

4. 改成自己的业务：商品增删改查与入库单事务的标准写法

4.1 参数化查询与登录验证：别再拼 SQL 字符串

老源码里最常见的写法是把文本框内容直接拼接进 SQL：

string sql = "SELECT * FROM t_User WHERE UserName='" + txtUser.Text + "' AND Password='" + txtPwd.Text + "'";

这条代码在课程设计里能跑，但文本里带单引号就崩，还留了 SQL 注入的口子。正确做法是参数化：

string sql = "SELECT COUNT(*) FROM t_User WHERE UserName=@name AND Password=@pwd"; using (SqlConnection conn = new SqlConnection(connStr)) using (SqlCommand cmd = new SqlCommand(sql, conn)) { cmd.Parameters.Add("@name", SqlDbType.NVarChar, 50).Value = txtUser.Text.Trim(); cmd.Parameters.Add("@pwd", SqlDbType.NVarChar, 50).Value = txtPwd.Text.Trim(); conn.Open(); int count = (int)cmd.ExecuteScalar(); if (count > 0) { // 记录当前登录人，打开主窗体 } }

参数类型按数据库列的类型来：varchar 用 SqlDbType.VarChar，nvarchar 用 SqlDbType.NVarChar。这里不用 AddWithValue，因为 AddWithValue 有时会把类型推断成 nvarchar 导致索引失效。数据量小看不出差别，养成显式声明类型的习惯更稳。登录验证只是第一步，后面所有查询都照这个模板走，能替你挡掉大量引号和编码问题。

4.2 商品列表与 DataGridView：绑定、列映射与刷新

商品管理是这类系统最标准的增删改查界面。查询逻辑是模板级别的：

string sql = "SELECT ProductId, ProductName, Spec, Unit, Stock FROM t_Product"; using (SqlConnection conn = new SqlConnection(connStr)) using (SqlDataAdapter adapter = new SqlDataAdapter(sql, conn)) { DataTable dt = new DataTable(); adapter.Fill(dt); dataGridView1.AutoGenerateColumns = false; dataGridView1.DataSource = dt; }

关键在最后两行。如果省略 AutoGenerateColumns = false，表格会自动按 DataTable 的列名生成列——数据库里叫 ProductName，界面就显示“ProductName”，难看还改不了。正确的做法是在设计器里预先定义好列：

dataGridView1.Columns["colName"].DataPropertyName = "ProductName"; dataGridView1.Columns["colSpec"].DataPropertyName = "Spec";

DataPropertyName 把界面列映射到数据源列，这样界面列宽、表头文字、是否只读都可以独立控制。数据改过之后，列表不刷新是个高频问题。数据源的 DataTable 换了一批数据，必须重新赋 DataSource，最好先置 null 再赋值：

dataGridView1.DataSource = null; dataGridView1.DataSource = dt;

这样才能触发控件重绘。新增和删除的 SQL 也是同套路：从当前选中行取主键，执行 INSERT 或 DELETE，再重新查询绑定。整套流程下来，你就掌握了 WinForms 做简单表格的全部核心操作。

4.3 入库单事务：主表、明细与库存联动的标准姿势

入库是仓库系统里最有代表性的业务。一张入库单包含一个主表记录和 N 行明细，还要把数量累加到库存表，这三步必须原子性完成——要么全成功，要么全失败。用 SqlTransaction 包起来：

using (SqlConnection conn = new SqlConnection(connStr)) { conn.Open(); SqlTransaction tran = conn.BeginTransaction(); try { string sqlMain = @"INSERT INTO t_InStock(InNo, SupplierId, BillDate, CreateUser) VALUES(@no, @supplier, @date, @user); SELECT SCOPE_IDENTITY();"; SqlCommand cmdMain = new SqlCommand(sqlMain, conn, tran); cmdMain.Parameters.Add("@no", SqlDbType.NVarChar, 30).Value = billNo; cmdMain.Parameters.Add("@supplier", SqlDbType.Int).Value = supplierId; cmdMain.Parameters.Add("@date", SqlDbType.DateTime).Value = DateTime.Now; cmdMain.Parameters.Add("@user", SqlDbType.NVarChar, 20).Value = currentUser; int billId = Convert.ToInt32(cmdMain.ExecuteScalar()); foreach (DataGridViewRow row in dgvDetails.Rows) { int pid = Convert.ToInt32(row.Cells["colPid"].Value); decimal qty = Convert.ToDecimal(row.Cells["colQty"].Value); decimal price = Convert.ToDecimal(row.Cells["colPrice"].Value); string sqlDetail = "INSERT INTO t_InStockDetail(BillId, ProductId, Qty, Price) VALUES(@billId, @pid, @qty, @price)"; SqlCommand cmdDetail = new SqlCommand(sqlDetail, conn, tran); cmdDetail.Parameters.Add("@billId", SqlDbType.Int).Value = billId; // @pid、@qty、@price 同样用 Parameters.Add 显式声明 string sqlStock = @"IF EXISTS(SELECT 1 FROM t_Stock WHERE ProductId=@pid) UPDATE t_Stock SET Qty = Qty + @qty WHERE ProductId=@pid; ELSE INSERT INTO t_Stock(ProductId, Qty) VALUES(@pid, @qty);"; SqlCommand cmdStock = new SqlCommand(sqlStock, conn, tran); // 添加参数并执行 } tran.Commit(); } catch { tran.Rollback(); throw; } }

SCOPE_IDENTITY() 拿到刚插入主表的自增主键，用这个 ID 去插明细，是一单多品的标准做法。注意所有 SqlCommand 都必须传入同一个 tran，少传一个，那一步就不再是事务的一部分，半途失败时会出现“主表已提交、明细没插完”的脏数据。遇到这种问题，重点检查每个 Command 构造函数的第三个参数是不是 tran。

4.4 模糊搜索与分页：两个马上能上线的列表能力

搜索框加在商品列表上是刚需。模糊查询用 LIKE，注意用参数拼接而不是字符串拼接：

SELECT ProductId, ProductName, Spec, Unit, Stock FROM t_Product WHERE ProductName LIKE '%' + @kw + '%' ORDER BY ProductId

C# 端照旧给 @kw 赋值。这里有个隐藏坑：如果用户输入的搜索词本身带 % 或 _，LIKE 会把它当通配符。稳妥做法是把这两个字符转义，或者在数据量不大的场景直接查回本地 DataTable 后用 String.Contains 做内存过滤，就不存在通配符转义问题。

分页在表格数据量超过几百行时就有必要了。老方案是把所有行查出来在内存里翻页，数据一多就卡。服务端分页的写法：

SELECT * FROM ( SELECT ROW_NUMBER() OVER (ORDER BY ProductId) AS RowNo, p.* FROM t_Product p ) AS T WHERE T.RowNo BETWEEN @start AND @end

@start 是 (页码-1)每页条数+1，@end 是页码每页条数。配一个 SELECT COUNT(*) FROM t_Product 查总行数，就能算出总页数。这种分页在 SQL Server 2005 及以上都能跑，新版本 SQL Server 的 OFFSET/FETCH 当然更简洁，但老 SQL Server 上 ROW_NUMBER 更稳，兼容性最好。

5. 避坑指南：从 sa 登录失败到数据库版本不兼容的 5 个现场

5.1 “sa 登录失败”多半不是密码错，是实例名或服务没起来

现象：启动登录窗点登录，几秒后报错，一种是“与 SQL Server 建立连接时出现与网络相关的或特定于实例的错误”，另一种是“用户 sa 登录失败（错误 18456）”。

原因：最常见的是连接字符串里实例名不对。装 Express 版后服务名带 \SQLEXPRESS，你写“.”连默认实例当然找不着；其次 SQL Server 服务没启动，或者禁用了 TCP/IP。

解决：先用 SSMS 确认实例名，再把 Data Source 改成“.\SQLEXPRESS”这种；打开 SQL Server 配置管理器，确认 SQL Server 服务是运行状态，TCP/IP 协议已启用。临时验证可以先用 sqlcmd -L 列出本机实例，也可以直接在命令行跑一句 sqlcmd -S .\SQLEXPRESS -U sa -P 密码，能进命令行就说明服务没毛病，问题一定出在配置上。

注意：sa 密码是安装 SQL Server 时设置的，不是默认空密码；如果忘了，可以用 Windows 身份认证进 SSMS，在安全里重置 sa 密码。

5.2 SQL 脚本执行后中文全变问号

现象：执行 .sql 建库脚本，插入的中文数据在表里全是“???”，界面查出来也乱码。

原因：脚本文件本身是 UTF-8 或 GBK 编码，但 SSMS 打开时按默认编码解析错了；或者建库时用了默认排序规则，对中文不友好。

解决：建库时显式指定排序规则，例如 CREATE DATABASE CangKu COLLATE Chinese_PRC_CI_AS。执行脚本时，如果文件是 UTF-8 无 BOM 编码，SSMS 可能按本地 ANSI 码解析，导致中文丢失。在 SSMS 的“文件→高级保存选项”里把脚本另存为“UTF-8 带签名”编码再执行，能解决一部分乱码。乱码修完后，已经写坏的数据要 DELETE 重插，不是只改排序规则就自动恢复的。

5.3 附加数据库提示“版本 852”，高版本文件装不进低版本

现象：附加 .mdf 或还原 .bak 时，SQL Server 报“数据库的版本为 852，无法打开”。

原因：852 对应 SQL Server 2016 的文件格式。你的 SQL Server 版本低于文件生成版本，SQL Server 文件只能向上兼容、不能向下还原。

解决：三条路。一是装一个 SQL Server 2016 或更高版本来附加；二是在高版本上附加后，用“生成脚本”把库结构和数据导成 .sql，再到低版本执行；三是干脆统一用 SQL Server 2019 Developer，把源数据库也升级到同版本。不要试图手动改 .mdf 头文件版本号，改完库大概率损坏，没有后悔药。

5.4 编译报“未能找到类型或命名空间名 XXX”，先看引用列表

现象：编译时红波浪，错误信息形如“未能找到类型或命名空间名‘Skin’”，或者运行时 FileNotFoundException。

原因：项目 References 里有黄色感叹号——某个 DLL 引用了绝对路径，源码包拷到别的机器后路径失效；或者第三方组件需要单独安装。

解决：右键解决方案“管理 NuGet 程序包”先还原缺失包；如果是皮肤、报表这类需要手动引用的 DLL，去源码包目录找有没有附带 DLL，有就手动添加到 References。添加时注意目标平台：64 位系统下 x86 的 DLL 在 AnyCPU 下不一定加载，把项目平台改成 x86 再试。排查顺序建议是：先看 Bin 目录有没有这个 DLL，再看 GAC，最后看 NuGet，别一上来就重装 VS。

5.5 列表不刷新，改了 DataTable 界面还是老样子

现象：新增一条商品后，调用查询方法重新绑定 DataSource，DataGridView 上还是旧的，或者出现重复列。

原因：忘了置空再绑定。同一个 DataTable 实例内容变了，只重新赋给 DataSource，WinForms 可能不重绘；AutoGenerateColumns 没关闭也会叠加新列。

解决：刷新前先 dataGridView.DataSource = null，再赋新 DataTable；如果用了 BindingSource，调 ResetBindings(false)。判断是不是数据源问题，可以在绑定前用 MessageBox 看看 DataTable 行数，别一上来怀疑控件坏了。这个坑在状态栏刷新、进度条更新的场景里同样适用——UI 绑定的数据源只要换了实例，就必须重新赋值。

6. 从能跑到好用：界面美化、状态栏进度与打包分发

很多人跑通源码后就停手了，其实还有三件事能让系统真正被别人用起来。

第一是界面美化。WinForms 默认灰底控件确实丑，但别急着引第三方皮肤。先把现有窗体的 Font 统一成微软雅黑 9pt，Button 的 FlatStyle 设成 Flat，BackColor 靠近主菜单色，表格开启自动列宽度，廉价方案也能看得过去。如果要用皮肤组件（社区常用的 IrisSkin 这类），注意两点：DLL 要随主程序一起分发，版本要匹配目标 .NET Framework，老项目升级框架后皮肤失效是常见翻车现场。菜单折叠如果用 MenuStrip 默认不顺手，常见做法是换成 TreeView 响应用户双击事件，给按钮做一个选中态标记，比硬调系统的折叠箭头绘制省事得多。

第二是操作反馈。仓库系统里导入导出、报表生成都是耗时操作，直接在 UI 线程里跑循环，窗体就“假死”。常规做法是用 BackgroundWorker，进度条和状态栏联动更新：

BackgroundWorker worker = new BackgroundWorker(); worker.WorkerReportsProgress = true; worker.DoWork += (s, e) => { for (int i = 0; i <= 100; i += 10) { Thread.Sleep(200); // 模拟耗时，需 using System.Threading; worker.ReportProgress(i); } }; worker.ProgressChanged += (s, e) => { toolStripProgressBar1.Value = e.ProgressPercentage; toolStripStatusLabel1.Text = "处理中 " + e.ProgressPercentage + "%"; }; worker.RunWorkerAsync();

进度条和状态栏文字的更新必须放在 ProgressChanged 里，不要直接在 DoWork 里碰控件，跨线程访问控件会抛异常。DoWork 里只做数据和业务处理。

第三是打包分发。开发机上跑通不算完，目标电脑不一定装了 .NET 运行时和 SQL Server。常见做法是：用 VS 自带的 Setup Project（VS2015 后 InstallShield 被移除，需要装 Visual Studio Installer Projects 扩展）或 Inno Setup 打安装包，把 .NET Framework、SQL Express 和数据库脚本作为前置条件带上。更精细一点的是做一个首次运行配置向导，让用户安装时输入数据库实例名、账号密码，再把连接字符串写进 exe 同目录的配置文件，而不是硬编码。

我自己的早期项目就在这上面栽过跟头：连接字符串直接写在 Form1.cs 里，打包后全公司一台台改成自己的机器名，每换一台电脑就要重新编译一次。后来我把连接字符串抽到 App.config，用向导保存成独立配置文件，数据库脚本做成静默安装——从那次以后，新电脑部署从一天变成十分钟。这套仓库管理系统你照着这个节奏改，先跑通、再美化、最后打包，就能从一份课程设计变成真正能交付的生产工具。希望帮到你。

本文还有配套的精品资源，点击获取