简介：面向使用C#开发相机采集与实时传输功能的中高级WinForms开发者，这套源码演示如何借助佳能EDSDK.dll完成相机连接、参数设置、拍照、图像下载与实时预览传输，并附最新版EOS SDK组件。压缩包共1792个文件、约134.97MB，主体为SDK运行所需的1518个bin数据与固件文件、104个dll动态库，另有102个icc与6个icm色彩配置文件、18个cs源码、2个csproj及sln解决方案，还包含少量txt说明、exe工具与资源文件，可在Visual Studio中直接打开研究。已有1332人学习下载。源码围绕相机控制逻辑展开，适合参考其会话初始化、拍照回调、图像保存与实时传输的实现方式，也可作为兼容多款EOS机型的二次开发与排错基础工程。
1. 从影棚联机到工位检测：这套 C# 控佳能相机源码到底能省多少事
影棚里拍产品图，摄影师盯着相机屏幕，助理在电脑上手动拷卡；工业检测工位上，相机固定在支架上，操作员按一下鼠标，图片才慢慢出现在上位机里。这两种场景的共同痛点是：相机和电脑之间隔着一层手动操作。这套C# 控制佳能相机拍照实时传输的源码，做的事就是把这一层拆掉——用C#直接调EDSDK.Dll，在代码里完成相机枚举、会话建立、快门触发、文件回传，以及实时取景画面的连续拉取，资源包里附带了最新版 EOS SDK，省去在官网翻文档、对版本号的环节。
它适合两类人：一类是做上位机、视觉工位、影棚联机软件的开发者，想拿一份能跑的骨架改业务逻辑；另一类是想把 EOS 机身当成可控采集设备来用，但被 C 风格 API 和 C# 互操作卡住的人。下面按“地基怎么打、快门怎么按、画面怎么流、坑在哪”的顺序拆，代码片段来自这份源码的主干，不保证一行不改就编译，但结构和调用次序是对的。
2. EDSDK 与 C# 互操作的地基：句柄、回调与 32/64 位对齐
EDSDK 本身是 C 接口的动态库，C# 要用它，绕不开三件事：函数签名怎么声明、结构体内存怎么排、回调委托怎么保命。这份源码的第一层价值就在这儿——它把EDSDK.dll的导出函数按CallingConvention.Cdecl包了一遍，把相机、列表、流都当成IntPtr句柄来管。很多人第一次接 EDSDK 就翻车在位数上：上位机编译成 AnyCPU，跑在 64 位系统上默认加载 64 位进程，而手头放的EDSDK.dll是 32 位的，运行时直接BadImageFormatException。源码里把 x86 和 x64 的 DLL 分目录放，这是对的做法，但你在自己项目里得确认输出目录跟着平台走。
2.1 SDK 目录结构与 DllImport 的落点
拿到资源后先别急着打开解决方案，先看 SDK 目录。常见结构是EDSDK/Dll/下按平台分子目录，EDSDK/Library/放 C# 包装或头文件示例，EDSDK/Documentation/放 API 参考。运行时真正被加载的只有EDSDK.dll（部分版本还带EdsImage.dll之类的辅助库），它必须和你的 exe 在同一目录，或者在PATH能找到的位置。源码里通常用“复制到输出目录”的方式处理，但如果你把项目挪了位置，这个复制规则会失效，症状是“代码编译过、一运行就报找不到模块”。
DllImport 的声明有几个固定点要盯：
using System; using System.Runtime.InteropServices; internal static class Edsdk { private const string Dll = "EDSDK"; // EDSDK 是 cdecl，写成 StdCall 在 x64 下可能侥幸，x86 下栈会乱 [DllImport(Dll, CallingConvention = CallingConvention.Cdecl)] internal static extern uint EdsInitializeSDK(); [DllImport(Dll, CallingConvention = CallingConvention.Cdecl)] internal static extern uint EdsTerminateSDK(); [DllImport(Dll, CallingConvention = CallingConvention.Cdecl)] internal static extern uint EdsGetCameraList(out IntPtr cameraList); [DllImport(Dll, CallingConvention = CallingConvention.Cdecl)] internal static extern uint EdsGetChildCount(IntPtr obj, out int count); [DllImport(Dll, CallingConvention = CallingConvention.Cdecl)] internal static extern uint EdsGetChildAtIndex(IntPtr obj, int index, out IntPtr child); [DllImport(Dll, CallingConvention = CallingConvention.Cdecl)] internal static extern uint EdsOpenSession(IntPtr camera); [DllImport(Dll, CallingConvention = CallingConvention.Cdecl)] internal static extern uint EdsCloseSession(IntPtr camera); [DllImport(Dll, CallingConvention = CallingConvention.Cdecl)] internal static extern uint EdsRelease(IntPtr obj); }这里每个声明都对应 SDK 文档里的一个导出函数，out IntPtr接的是 SDK 内部创建的句柄，用完必须EdsRelease，否则就是慢性泄漏。CallingConvention.Cdecl不能省，这是 EDSDK 的调用约定，写错在 x86 下会直接把栈顶弄乱，表现为“第一次调用正常、第二次崩在奇怪的地方”。Dll常量不带.dll后缀是让 CLR 自己按平台找，但如果你同时放了 32/64 位两个同名 DLL 在同一目录，加载哪个就成玄学了——所以别偷懒，按平台分目录。
2.2 句柄、回调与错误码：把 C 风格 API 包成 C# 能用的形状
EDSDK 的返回值统一是uint错误码，EDS_ERR_OK = 0。源码里一般会包一个Check方法，非零就抛异常或记日志，别学某些示例直接忽略返回值——相机没连上时EdsOpenSession返回非零，你后面所有调用都会连环失败，日志里只有一个“拍照失败”，排查成本极高。
回调是第二个坎。EDSDK 通过EdsSetObjectEventHandler注册对象事件回调，拍照完成后 SDK 会回调“目录项已创建”或“请求传输”。C# 里要把委托传给非托管代码，必须保证委托实例在回调期间不被 GC 回收：
// 委托类型要和 SDK 头文件里的 EdsObjectEventHandler 对上 [UnmanagedFunctionPointer(CallingConvention.Cdecl)] internal delegate uint EdsObjectEventHandler(uint inEvent, IntPtr inRef, IntPtr inContext); // 关键：把委托实例存成静态字段或类字段，否则 GC 一收就回调到野指针 private static EdsObjectEventHandler _objectHandler; internal static void RegisterObjectEvent(IntPtr camera) { _objectHandler = OnObjectEvent; // 先赋值再注册 uint err = EdsSetObjectEventHandler(camera, 0x00000200 /* kEdsObjectEvent_All */, _objectHandler, IntPtr.Zero); Check(err, "EdsSetObjectEventHandler"); } private static uint OnObjectEvent(uint inEvent, IntPtr inRef, IntPtr inContext) { // 回调线程不是 UI 线程，别在这里直接摸控件 if (inEvent == 0x00000207 /* DirItemCreated */ || inEvent == 0x00000208 /* DirItemRequestTransfer */) { // 交给后台队列处理，回调里只做最小动作 TransferQueue.Enqueue(inRef); } return 0; }inEvent是事件类型，inRef是本次事件关联的对象句柄，可能是目录项也可能是相机对象，要按事件类型区分。回调运行在 SDK 自己的线程上，直接在里面更新 WinForm/WPF 控件会抛跨线程异常，常见做法是入队后由 UI 定时器或后台线程消费。源码里如果用了BeginInvoke，注意别在窗体已经关闭后还往里投递，否则对象已释放的异常会盖住真正的业务错误。
2.3 最小可跑流程：初始化、枚举、打开会话
把上面几块拼起来，一个最小流程是：EdsInitializeSDK→EdsGetCameraList→ 取第一个相机 →EdsOpenSession→ 注册回调 → 业务 →EdsCloseSession→EdsTerminateSDK。源码里一般还会在打开会话后设置保存目标为 Host（即电脑端），这样拍照后文件不会只留在卡里：
public static IntPtr OpenFirstCamera() { Check(EdsInitializeSDK(), "EdsInitializeSDK"); Check(EdsGetCameraList(out IntPtr list), "EdsGetCameraList"); Check(EdsGetChildCount(list, out int count), "EdsGetChildCount"); if (count == 0) { EdsRelease(list); throw new InvalidOperationException("没有发现相机"); } Check(EdsGetChildAtIndex(list, 0, out IntPtr camera), "EdsGetChildAtIndex"); EdsRelease(list); // 列表句柄用完即放，相机句柄留着 Check(EdsOpenSession(camera), "EdsOpenSession"); // 设置保存目标：1 = Host，2 = Camera。联机传输场景选 Host uint saveTo = 1; Check(EdsSetPropertyData(camera, 0x0000000B /* kEdsPropID_SaveTo */, 0, 4, ref saveTo), "Set SaveTo"); RegisterObjectEvent(camera); return camera; }kEdsPropID_SaveTo的取值要跟相机能力匹配，有的机型在 Host 模式下还要调EdsSetCapacity告诉相机主机端可用空间，否则拍照会返回“存储介质不可用”。这一步源码里如果没写，你可以补一个EdsCapacity结构体，把NumberOfFreeClusters和BytesPerSector填个保守值，比如 1000 和 4096，先让流程跑通，再按实际磁盘容量调。
3. 拍照与文件回传：从按下快门到文件落盘的完整时序
拍照这件事在 EDSDK 里不是“调一个函数就拿到图片”，而是“发命令触发快门 → SDK 回调通知目录项创建 → 你请求传输 → 分块下载 → 通知完成”。这份源码的主干就是把这条链路的时序写顺了，尤其是“回调里拿到的目录项句柄归谁释放”这个容易写错的地方。
3.1 触发拍照与对象事件
触发快门用EdsSendCommand，命令号是kEdsCameraCommand_TakePicture（0x00000000）。但发命令之前，要确认相机处于可拍摄状态，常见做法是读一下kEdsPropID_CurrentStorage或直接看会话是否正常。发命令本身是异步的，函数返回只代表命令送达，不代表照片已经生成。真正的“照片好了”信号是对象事件回调里的DirItemCreated或DirItemRequestTransfer。
源码里一般会在DirItemRequestTransfer事件里直接发起下载，因为这时 SDK 已经准备好把文件交给你。要注意inRef是一个目录项句柄，回调返回后 SDK 可能回收它，所以要么在回调里同步下载完，要么先EdsRetain增加引用计数再丢给后台线程。很多示例图省事直接在回调里下载，文件小的时候没事，文件大了会阻塞 SDK 的事件线程，表现为“连拍几张后相机没反应”。
private static void OnObjectEvent(uint inEvent, IntPtr inRef, IntPtr inContext) { if (inEvent == 0x00000208 /* DirItemRequestTransfer */) { // 增加引用，防止回调返回后句柄失效 EdsRetain(inRef); Task.Run(() => DownloadItem(inRef)); } } private static void DownloadItem(IntPtr dirItem) { try { Check(EdsGetDirectoryItemInfo(dirItem, out EdsDirectoryItemInfo info), "EdsGetDirectoryItemInfo"); string fileName = Path.Combine(_saveDir, info.szFileName); Check(EdsCreateFileStream(fileName, 1 /* CreateAlways */, 1 /* ReadWrite */, out IntPtr stream), "EdsCreateFileStream"); Check(EdsDownload(dirItem, info.size, stream), "EdsDownload"); Check(EdsDownloadComplete(dirItem), "EdsDownloadComplete"); EdsRelease(stream); } finally { EdsRelease(dirItem); // 和前面的 EdsRetain 配对 } }EdsDirectoryItemInfo是个结构体，字段顺序和字符集要对，szFileName按 ANSI 字符数组声明，长度一般 256。EdsCreateFileStream的第二个参数是创建方式，第三个是访问模式，填错会返回参数错误。下载完成后必须调EdsDownloadComplete，这是告诉相机“这个文件我收好了”，否则相机端可能一直占着资源。
3.2 下载参数与落盘策略
文件名冲突是联机拍摄里最常见的问题。相机生成的文件名按IMG_0001.JPG递增，但换卡、换机身、格式化后都可能重名。源码里如果直接Path.Combine就写，第二次拍摄会覆盖第一张。稳妥做法是落盘前做一次重命名，或者按“日期_序号_原文件名”的规则拼：
private static string BuildUniquePath(string dir, string originalName) { string name = Path.GetFileNameWithoutExtension(originalName); string ext = Path.GetExtension(originalName); string candidate = Path.Combine(dir, originalName); int index = 1; while (File.Exists(candidate)) { candidate = Path.Combine(dir, $"{name}_{index:000}{ext}"); index++; } return candidate; }这段逻辑不复杂，但它决定了你连续拍几百张后要不要手工去重。另一个参数是保存目录的权限，工位机器上常见的是程序装在Program Files下，默认没有写权限，EdsCreateFileStream返回非零，日志里只看到“下载失败”。把保存目录放到D:\Capture这类可写路径，或者启动时先做一次目录可写性检查，能省掉很多现场排查。
3.3 拍照链路的关键参数表
| 参数/常量 | 含义 | 常见取值 | 注意点 |
|---|---|---|---|
kEdsCameraCommand_TakePicture | 触发快门命令 | 0x00000000 | 异步，返回不代表已生成文件 |
kEdsObjectEvent_DirItemRequestTransfer | 请求传输事件 | 0x00000208 | 在这里发起下载最稳 |
kEdsPropID_SaveTo | 保存目标 | 1=Host，2=Camera | Host 模式才走电脑端回传 |
EdsFileCreateDisposition.CreateAlways | 文件创建方式 | 1 | 覆盖同名文件，需自行去重 |
EdsAccess.ReadWrite | 流访问模式 | 1 | 只读流下载会失败 |
EdsDirectoryItemInfo.size | 文件字节数 | 由 SDK 填充 | 传给EdsDownload的总长度 |
这张表里的值来自 SDK 头文件的枚举定义，不同版本可能有细微差别，拿到新版 SDK 后建议先跑一遍枚举打印，确认常量没变。尤其是SaveTo的取值，有的文档写 1 是 Host、2 是 Camera，有的示例反过来，最保险的方式是看头文件里EdsSaveTo的定义，别凭记忆。
4. 实时取景与画面回传：把 LiveView 帧流接进 C# 界面
“实时传输”在这个资源里通常指两件事：拍照后的文件回传，以及实时取景（LiveView）画面的连续拉取。前者是离散的，后者是连续的，对代码结构的要求完全不同。LiveView 的核心是让相机把取景画面输出到 PC，然后你不断从 SDK 的内存流里取帧、转成Bitmap、刷到界面上。这块如果写不好，症状是画面卡顿、内存一路涨、或者跑几分钟后相机掉线。
4.1 启动 LiveView 与取帧循环
启动 LiveView 要先设置kEdsPropID_Evf_OutputDevice为 PC 端，再打开kEdsPropID_Evf_Mode。有的机型还需要先设置kEdsPropID_Evf_DepthOfFieldPreview之类的属性，但基础流程就这两步。取帧不是事件驱动，而是主动轮询：创建一个内存流，调EdsCreateEvfImageRef和EdsDownloadEvfImage，然后从流里拿指针和长度。
private static IntPtr _evfStream; private static void StartLiveView(IntPtr camera) { uint device = 2; // kEdsEvfOutputDevice_PC Check(EdsSetPropertyData(camera, 0x00000500 /* Evf_OutputDevice */, 0, 4, ref device), "Set Evf OutputDevice"); uint mode = 1; Check(EdsSetPropertyData(camera, 0x00000501 /* Evf_Mode */, 0, 4, ref mode), "Set Evf Mode"); // 内存流大小给个 4MB，够大多数机型的 JPEG 帧 Check(EdsCreateMemoryStream(4 * 1024 * 1024, out _evfStream), "CreateMemoryStream"); } private static Bitmap GrabFrame(IntPtr camera) { Check(EdsCreateEvfImageRef(_evfStream, out IntPtr evfImage), "CreateEvfImageRef"); try { Check(EdsDownloadEvfImage(camera, evfImage), "DownloadEvfImage"); Check(EdsGetPointer(_evfStream, out IntPtr data), "GetPointer"); Check(EdsGetLength(_evfStream, out ulong length), "GetLength"); byte[] buffer = new byte[(int)length]; Marshal.Copy(data, buffer, 0, buffer.Length); using (var ms = new MemoryStream(buffer)) { return new Bitmap(ms); // 帧是 JPEG，直接交给 GDI+ 解码 } } finally { EdsRelease(evfImage); // 每帧都要放，别攒着 } }这段代码的关键在finally里的EdsRelease(evfImage)。EdsCreateEvfImageRef每帧创建一个图像引用，不放就是每帧泄漏一点，跑十分钟内存能涨几百兆。EdsDownloadEvfImage返回非零时不要当致命错误，相机在自动对焦或切换参数时偶尔会返回忙，重试下一帧即可。
4.2 帧数据转 Bitmap 与 UI 刷新
取到的帧是 JPEG 字节流，用MemoryStream+Bitmap解码是最省事的写法，但要注意Bitmap持有流的问题：在某些 .NET 版本里，new Bitmap(stream)要求流在 Bitmap 生命周期内保持打开，直接using掉流会偶发“参数无效”。稳妥做法是解码后立刻深拷贝一份，或者用Image.FromStream后Clone成新位图。源码里如果直接赋给PictureBox.Image，记得把上一帧的 BitmapDispose，否则 GDI 句柄会涨。
刷新频率别跟着相机帧率走。多数 EOS 机型的 LiveView 输出在 30fps 左右，但 C# 界面按 30fps 重绘已经够呛，工位上还同时跑着其他逻辑。常见做法是用一个 30~50ms 的定时器取帧，取到就刷，取不到就跳过，UI 线程只做赋值。取帧动作放后台线程，避免EdsDownloadEvfImage阻塞消息循环导致界面“假死”。
4.3 性能与释放：帧率、内存与掉线
LiveView 跑久了掉线，八成是资源没释放干净或者 USB 带宽被占满。除了每帧释放evfImage，还要注意EdsCreateMemoryStream创建的流在整个会话期间只创建一次，别每帧建一个新流。内存流的容量如果小于实际帧大小，EdsDownloadEvfImage会返回错误，4MB 对大多数 JPEG 帧够用，但如果你把画质调到最高、帧又大，可以加到 8MB。
另一个容易被忽略的点是相机端的 LiveView 状态。程序退出前要先把Evf_Mode设回 0，再关会话，否则下次打开可能提示“设备忙”。工位机器上如果用了 USB Hub，尽量把相机插在根端口上，Hub 供电不足时表现为“取景几秒后黑屏”，换根线或者换端口往往就好了。这些不是代码能完全解决的问题，但源码里如果带了重连逻辑，至少能让程序自己恢复，不用重启。
5. 避坑与排查：五个把我按在地上摩擦的现场问题
这一章按“现象 → 原因 → 解决”写，都是接 EDSDK 时高频出现的翻车点。顺序按从编译期到运行期排，方便你对照自己的现场。
5.1 一运行就报 BadImageFormatException
现象：解决方案编译通过，F5 启动瞬间抛BadImageFormatException，提示“试图加载格式不正确的程序”。
原因：进程位数和EDSDK.dll位数不一致。AnyCPU 在 64 位系统上默认跑 64 位进程，而你复制到输出目录的是 32 位 DLL；或者反过来，项目设了 x86，DLL 却是 64 位。
解决：把项目平台目标显式设成 x64 或 x86，别留 AnyCPU；按平台把对应目录的 DLL 复制到输出目录，清理掉另一份同名文件。发布时在安装包里按目标机器架构选 DLL，别一份包打天下。
5.2 拍照回调偶尔不触发，或者触发几次后程序崩
现象：单张拍摄正常，连拍几张后回调不再进来；或者运行一段时间直接崩在OnObjectEvent里。
原因：委托实例被 GC 回收，SDK 回调到已释放的托管对象；或者回调里做了耗时操作，把 SDK 的事件线程堵死。
解决：把回调委托存成静态字段或长生命周期对象的字段，确保注册期间一直有强引用；回调里只做入队、EdsRetain这类轻量动作，下载和 UI 更新丢给后台线程。崩的时候看崩溃地址是不是在托管堆，是的话优先查委托生命周期。
5.3 下载文件大小是 0，或者只下了一半
现象：EdsDownload返回成功，但落盘文件 0 字节；或者大文件下到一半就停。
原因：EdsCreateFileStream的访问模式传了只读；或者EdsDownload的长度参数用了int截断；或者下载过程中流被提前释放。
解决：创建流时用ReadWrite；长度统一用ulong接EdsDirectoryItemInfo.size；下载完必须调EdsDownloadComplete再释放流。文件大小对不上时，先打印 SDK 返回的size和实际写入字节数，定位是下载截断还是写盘失败。
5.4 相机连上了但一拍照就报“设备忙”
现象：EdsOpenSession成功，取景也正常，一按快门返回非零，提示设备忙或存储不可用。
原因：相机被其他软件占用（比如官方联机工具还开着）；或者SaveTo设成了 Host 但没调EdsSetCapacity，相机不知道主机端有多少空间。
解决：关掉所有可能占用相机的程序，包括后台常驻的图片服务；Host 模式下补一个EdsCapacity设置，给个保守的可用空间值。如果还是忙，把SaveTo临时改成 Camera，拍完再从卡里读，能区分是传输链路问题还是相机状态问题。
5.5 LiveView 画面越来越卡，最后黑屏
现象：刚启动取景流畅，跑几分钟后帧率下降，十几分钟后画面停住，但程序没崩。
原因：每帧创建的evfImage没有EdsRelease，内存和 SDK 内部句柄持续增长；或者取帧频率高于相机输出能力，USB 带宽被占满。
解决：每帧在finally里释放evfImage；取帧定时器间隔设到 30~50ms，别用while(true)死循环；退出前把Evf_Mode设回 0。如果换端口能缓解，说明是供电或 Hub 问题，别在代码里死磕。
6. 进阶：把 SDK 关进独立进程，顺带解决重连与验证
源码能跑通之后，下一步不是加业务按钮，而是把相机操作从 UI 进程里挪出去。EDSDK 是原生库，一旦它内部崩了，整个上位机跟着退，工位上没人会看你的异常日志，只会看到“软件又没了”。我一般的做法是起一个轻量的相机服务进程，UI 通过命名管道或本地 socket 发指令，服务进程负责EdsInitializeSDK、会话保持、拍照和取帧。这样 SDK 崩了只崩服务，UI 弹个重连提示，服务进程拉起来就能继续。
服务进程里的状态机要简单：未初始化 → 已初始化 → 会话打开 → 取景中。每个状态只接受有限指令，比如“取景中”不接受重复的OpenSession，避免把相机搞成半开半闭。重连逻辑放在服务进程启动阶段：初始化失败等 2 秒重试，连续失败 5 次再上报 UI。别在拍照失败时立刻重连，先区分是“相机忙”还是“句柄失效”，前者重试拍照，后者才重建会话。
验证这套东西是否稳定，我习惯跑一个 30 分钟的压测脚本：每 5 秒拍一张、持续取景、记录每次调用的返回码和耗时。下面这张表是我会看的几个指标，超过阈值就说明有资源没释放或者链路不稳。
| 指标 | 采集方式 | 正常范围 | 异常含义 |
|---|---|---|---|
| 拍照返回码 | 每次EdsSendCommand后记录 | 全 0 | 非 0 集中出现说明会话或存储异常 |
| 单张下载耗时 | 下载开始到DownloadComplete | 与文件大小线性相关 | 突然变长可能是 USB 降速或磁盘忙 |
| 进程私有内存 | 任务管理器或Process.PrivateMemorySize64 | 30 分钟内波动小于 20% | 持续上涨说明句柄或 Bitmap 没放 |
| 取景帧间隔 | 定时器实际触发间隔 | 30~60ms | 明显漂移说明 UI 线程被阻塞 |
压测脚本不用写得多漂亮，能循环、能记日志、能把返回码落文件就行。跑完看日志里有没有连续的非零返回，比盯着界面看半天靠谱。还有一个小技巧：把每次会话的EdsOpenSession和EdsCloseSession成对打日志，出现“开了没关”的会话，基本就能定位到是哪条异常路径漏了finally。
这套源码我前后改过几版，最深的教训是别信“示例能跑就行”。有一次在现场，单张拍摄怎么都正常，连拍二十张后必崩，查了一下午才发现回调委托被 GC 收了——示例里把委托写成局部变量，编译器优化一开就出事。从那以后我每次接原生回调，都先把委托字段声明成静态的，再注册，压测跑满三十分钟才往上交。希望帮到你。
本文还有配套的精品资源，点击获取
