库需要引用System.Windows.Forms [英] Library requires reference to System.Windows.Forms

查看:331
本文介绍了库需要引用System.Windows.Forms的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我无法找到有关此主题的信息,可能是因为我不确定如何表达问题。希望这里的人才可以帮助或至少提供建议。这种情况可能只是我固执己见,但却困扰着我,所以我想寻求有关如何解决它的帮助。

I'm having trouble finding information on this topic, possibly because I'm not sure how to phrase the question. Hopefully the braintrust here can help or at least advise. This situation might just be me being retentive but it's bugging me so I thought I'd ask for help on how to get around it.

我有一个C#库,里面满是其他程序集中使用的实用程序类。我所有的扩展都驻留在该库中,并且非常方便。我需要使用这些类的任何其他库或可执行文件都必须自然地引用该库。

I have a C# library filled with utility classes used in other assemblies. All of my extensions reside in this library and it comes in quite handy. Any of my other libraries or executables that need to use those classes must naturally reference the library.

但是我拥有的扩展之一是Control类的扩展以较少复杂的方式处理跨线程控制更新。结果,实用程序库必须引用System.Windows.Forms。

But one of the extensions I have in there is an extension on the Control class to handle cross thread control updates in a less convoluted fashion. As a consequence the utility library must reference System.Windows.Forms.

问题是,引用该实用程序库的任何库或可执行文件现在都必须具有对System的引用。 Windows.Forms还是因为缺少参考而出现构建错误。尽管这没什么大不了的,但是看起来与程序集或控件无关的程序集必须引用System.Windows.Forms似乎有点愚蠢,只是因为实用程序库会这样做,尤其是因为大多数实用程序库实际上并未使用我写过InvokeAsRequired()扩展名。

The problem being that any library or executable that references the utilities library must now have a reference to System.Windows.Forms as well or I get a a build error for the missing reference. While this is not a big deal, it seems sort of stupid to have assemblies that have nothing to do with controls or forms having to reference System.Windows.Forms just because the utilities library does especially since most of them aren't actually using the InvokeAsRequired() extension I wrote.

我考虑过将InvokeAsRequired()扩展名移至它自己的库中,这样可以消除Sys​​tem.Windows.forms问题,因为它仅是可以汇编的程序集需要使用InvokeAsRequired()扩展名就已经有对SWF的引用....但是后来我有了一个只包含一件事的库,这可能会使我更加烦恼。

I thought about moving the InvokeAsRequired() extension into it's own library, which would eliminate the System.Windows.forms problem as only assemblies that needed to use the InvokeAsRequired() extension would already have a reference to SWF.... but then I'd have a library with only one thing in it which will probably bother me more.

除了分离出违规方法并创建几乎为空的库之外,是否还有其他方法可以解决此需求?也许是编译设置?

Is there a way around this requirement beyond separating out the 'offending' method and creating a nearly empty library? Maybe a compile setting or something?


  • 应注意,冒犯方法实际上是在具有UI的多个项目中使用的。我进行的许多UI更新都是由于事件进入而导致的,并且尝试从另一个线程更新Windows窗体控件会导致各种UI线程问题。因此,在需要时处理调用的方法。 (尽管我个人认为整个InvokeRequired模式应该包装在控件本身中,而不是首先在外部进行线程对齐。)

推荐答案

如果只是一个功能,则将其作为源代码打包到NuGet包中,然后将NuGet包添加到您的项目中。然后,该代码将可以轻松地部署到新项目中(以及易于更新),但是您无需创建单独的程序集。只需将其编译到您的应用程序中即可。

If it's just one function, then package it up as a source code file into a NuGet package and then add the NuGet package to your projects. Then, this code will be easily deployable to new projects (as well as easily updateable), but you don't need to create a separate assembly. Just compile it into your application.

然后,您可以将NuGet包存储在本地NuGet存储库中,或者获取一个myget帐户,甚至只是将其存储在网络中的某个位置。最坏的情况是,您可以将其检入版本控制中,但我只是检入从中构建nuget软件包的项目,因此可以根据需要重建该软件包。

You would then store your NuGet package in a local NuGet repository, or get a myget account, or even just store it somewhere on your network. Worst case, you can check it into your version control, but I would just check in the "project" that you build the nuget package from, so you can rebuild the package if need be.

谁知道,在某个时候,您可以添加更多需要Windows窗体的实用程序功能,到那时,您可以证明一个单独的程序集是合理的。

Who knows, at some point, you may add more utility functions that require windows forms, and at that point you could justify a separate assembly.

这篇关于库需要引用System.Windows.Forms的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆