fo-dicom库 Dicom.Native.dll如何自动到编译输出目录

fo-dicom



全称:Fellow Oak DICOM

是一个处理 DICOM 协议及图像相关的类库,基于 .Net 平台。

问题



通过 nuget 将 fo-dicom 添加到项目,编译后 Dicom.Native.dll 没有自动拷贝到 编译输出目录。

Dicom.Native.dll 跟接收和处理 DICOM 图像有密切的关系

解决办法



以下是 github 上的方法,大致意思是 将项目编译配置 cpu 指令架构指定为 x86 或者 x64.

When installing fo-dicom via NuGet, a build script fo-dicom.targets is inserted into the Visual Studio project. This build script is responsible for fetching the Dicom.Native*.dll associated with the current build architecture to the build output (/bin) folder.

The fetch procedure only works if the build architecture of the project is set to either x86 (fetches Dicom.Native.dll) or x64 (fetches Dicom.Native64.dll), otherwise you will be prompted in the build log to select an appropriate build architecture.

This means that, when installing via NuGet, you will be able to sufficiently build your fo-dicom referencing application or class library even in the Any CPU architecture setting, but you will not be able to access the native codecs since these libraries will not be copied to the build output folder. To sufficiently access the native codecs via your application, please make sure that the project build architecture is set to x86 or x64.

https://github.com/fo-dicom/fo-dicom/wiki/Native-codecs-on-.NET

原文地址:https://www.cnblogs.com/junejs/p/12687094.html

时间: 2024-11-13 11:22:50

fo-dicom库 Dicom.Native.dll如何自动到编译输出目录的相关文章

DICOM:DICOM三大开源库对比分析之“数据加载”

背景: 上一篇博文DICOM:DICOM万能编辑工具之Sante DICOM Editor介绍了DICOM万能编辑工具,在日常使用过程中发现,"只要Sante DICOM Editor打不开的数据,基本可以判定此DICOM文件格式错误(准确率达99.9999%^_^)".在感叹Sante DICOM Editor神器牛掰的同时,想了解一下其底层是如何实现的.通过日常使用以及阅读软件帮助手册推断其底层依赖库很可能是dcmtk,就如同本人使用dcmtk.fo-dicom.dcm4che3等

DICOM:DICOM开源库多线程分析之“ThreadPoolQueue in fo-dicom”

背景: 上篇博文介绍了dcm4chee中使用的Leader/Follower线程池模型,主要目的是节省上下文切换,提高运行效率.本博文同属[DICOM开源库多线程分析]系列,着重介绍fo-dicom中使用的ThreadPoolQueue线程池. ThreadPoolQueue in fo-dicom: 先看一下ThreadPoolQueue代码中自定义的数据结构, public class ThreadPoolQueue<T> { private class WorkItem { public

DICOM:DICOM Print 服务详细介绍

背景: 昨天专栏中发表了一篇关于DICOM Print的博文DICOM:DICOM Print服务中PresentationContext协商之 MetaSOPClass与SOPClass对比分析,文章从部署中遇到的实际情况出发,对DICOM Print中的连接协商(Association Negotiation)进行了剖析,本文可看做是上一篇博文的补充,重新浏览和整理了DICOM3.0标准中对DICOM Print 服务的介绍,加深对DICOM打印的理解. DICOM Print服务数据流:

易语言支持库 找不到指定的命令/子程序/Dll命令调用名称“取特定目录”。

例如: 运行 (取特定目录 (#windos系统目录)+"\calc.exe",假) 输出框: 错误(37): 找不到指定的命令/子程序/Dll命令调用名称“取特定目录”. 编译现行易程序失败或被中止! 解决:在支持库配置里勾选操作系统界面功能支持库即可. 或者:运行(“notepad.exe”,假,) 参考:http://bbs.eyuyan.com/simple/?t236023.html

关于生产库的表空间是否自动扩展的看法?

我觉得 既然ORACLE设置了自动扩展 必然有其意图. 如何在生产环境使用手动还是自动呢? 主要看生产环境问题. 一是看业务产生的数据量的问题, 一次扩展数据文件大小多少,20M会不会太频繁,1G会不会磁盘操作时间太长. 自动扩展会影响下性能. 性能主要看你的硬件配置情况. 二手动扩展好处是 可以在业务低峰期扩大数据文件, 唯独麻烦的是管理麻烦,如果来不急人工添加数据文件,岂不是影响到业务的运营? 三是自动扩展,数据文件所在的硬盘是否足够,Linux下是32GB  会不会被其他文件所霸占掉? 注

.NET Native:将.NET应用编译为原生应用

什么是.NET Native? .NET Native是 一套在Visual Studio 2015中编译通用Windows(UWP)应用的预编译工具,它可以将托管的中间语言二进制文件编译为本地二进制文件,每一个托管的通用Windows 应用都将受益于这项新技术.在用户设备上安装之前,应用会自动编译为原生代码.有关其工作机制的详情可以查看MSDN. .NET Native会带来什么? 根据不同的情况,.NET Native所带来的好处各种各样.不过在大多数情况下,.NET Native将会使得应

搭建服务器上的GIT并实现自动同步到站点目录(www)

原文链接:http://blog.csdn.net/baidu_30000217/article/details/51327289  方便自己记住使用 前言:当我们想要实现几个小伙伴合作开发同一个项目,或者建立一个资源分享平台的时候,GIT就是一个很好的选择.当然,既然是一个共有平台,那么把这个平台放到个人计算机上明显是不合适的,因此就要在服务器上搭建GIT了.另一个需求是,我们在本地开发,然后推送到服务器上,并且自动同步到web站点目录,这样就可以直接看到网页效果了,这就要实现自动同步.下面我

使用函数自动生成n层目录

先检查是否已经存在该目录了,如果存在,则不做任何处理,如果不存在则创建. 希望对各位快速开发有用. CheckFolder.asp <% '*********************************************************************************************************** '作 者: 赵敏 [email protected] '页面名称: CreateFolder.asp '页面功能: 生成n层目录的文件夹 '使用

hadoop配置(4) --在每次运行时自动删除输出目录

运行 Hadoop 程序时,为了防止覆盖结果,程序指定的输出目录(如 output)不能存在,否则会提示错误,因此运行前需要先删除输出目录.在实际开发应用程序时,可考虑在程序中加上如下代码,能在每次运行时自动删除输出目录,避免繁琐的命令行操作: Configuration conf = new Configuration(); Job job = new Job(conf); /* 删除输出目录 */ Path outputPath = new Path(args[1]); outputPath