C# 使用外部文件或资源？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/848729/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Use external file or resource?
提问by Yaron Naveh
I am writing a C# application that uses a long "hard-coded" string.
我正在编写一个使用长“硬编码”字符串的 C# 应用程序。
For maintainability reasons I have decided to put this string in an external text file and load it. Is this a good idea? The extra I/O does not seem big in this case.
出于可维护性的原因，我决定将此字符串放在外部文本文件中并加载它。这是一个好主意吗？在这种情况下，额外的 I/O 似乎并不大。
I realize that I also have an option to embed this file as a .resx resource. Is this a better idea? The file will never need to be localized.
我意识到我还可以选择将此文件作为 .resx 资源嵌入。这是一个更好的主意吗？该文件永远不需要本地化。
采纳答案by Erv Walter
If you intend to allow users/administrators to change the string, I agree with the other answers, and I'd suggest putting it in settings.
如果您打算允许用户/管理员更改字符串，我同意其他答案，我建议将其放入设置中。
If you don't want it to be editable after deployment and it will only be modified by you and your developers, then I would put it in an embedded resource (note, this is not the same as a .resx file). You would read it at runtime like this:
如果您不希望它在部署后可编辑并且只能由您和您的开发人员修改，那么我会将其放入嵌入式资源中（注意，这与 .resx 文件不同）。你会在运行时像这样阅读它：
Assembly assembly = Assembly.GetExecutingAssembly();
Stream stream = assembly.GetManifestResourceStream(“MyAssemblyNamespace.MyTextFile.txt”);
StreamReader reader = new StreamReader(stream);
string theText = streamReader.ReadToEnd();
Update:This is solution that is easy to maintain. The .txt file will just be another file in your solution explorer in Visual Studio and you can edit it just like any other file, keep it under source control like any other file, etc. To turn it into an embedded resource by changing the Build Action in the properties window to "Embedded Resource".
更新：这是易于维护的解决方案。.txt 文件只是 Visual Studio 中解决方案资源管理器中的另一个文件，您可以像编辑任何其他文件一样编辑它，像任何其他文件一样将其置于源代码管理之下，等等。通过更改 Build 将其转换为嵌入式资源在属性窗口中操作“嵌入式资源”。
The end result is that your file(s) get embedded in your DLL so that you only have 1 DLL to distribute instead of a DLL and a folder of files that have to move around together.
最终结果是您的文件被嵌入到您的 DLL 中，因此您只有 1 个 DLL 可以分发，而不是一个 DLL 和一个必须一起移动的文件文件夹。
Update 2:Regarding "production debugging", this is a very static solution, and so you won't be able to change the contents of the text file at runtime because the file is baked into the DLL at compile time. For reading the contents of the file, you can use tools like reflectorto view the embedded resources of a DLL. You could also write a simple command line tool that dumps all the embedded .txt files from a DLL into individual files for you to look at.
更新 2：关于“生产调试”，这是一个非常静态的解决方案，因此您将无法在运行时更改文本文件的内容，因为该文件在编译时被烘焙到 DLL 中。要读取文件的内容，可以使用反射器等工具查看 DLL 的嵌入资源。您还可以编写一个简单的命令行工具，将所有嵌入的 .txt 文件从 DLL 转储到单独的文件中供您查看。
For memory usage, there isn't a solution more efficient than "I load it from a file into memory only exactly when it is needed". You have to decide whether the improved maintainability and deployment is worth the cost of a little extra memory when your DLL is loaded into memory for your specific situation. That said, you haven't said how large these files are. If they are really huge (megabytes+), I would probably notuse this solution and would go with loose files on the hard drive. If they are generally pretty small (hundreds of kilobytes), I wouldn't worry about the extra memory unless you are in some kind of embedded device situation where RAM is really tight.
对于内存使用，没有比“我仅在需要时才将它从文件加载到内存中”更有效的解决方案。当您的 DLL 被加载到您的特定情况的内存中时，您必须决定改进的可维护性和部署是否值得花费一点额外的内存。也就是说，您还没有说这些文件有多大。如果它们真的很大（兆字节+），我可能不会使用这个解决方案，并且会在硬盘驱动器上使用松散的文件。如果它们通常很小（数百 KB），我不会担心额外的内存，除非您处于某种 RAM 非常紧张的嵌入式设备情况。
回答by Vadim
I would suggest to use Application Settings.
我建议使用应用程序设置。
You can follow this MSDN link how to use Application and User Settings.
您可以按照此 MSDN 链接如何使用应用程序和用户设置。
回答by Andrew Hare
I would put this in an application configuration file.
我会把它放在一个应用程序配置文件中。
回答by Shane Fulmer
Even better would be to add a Settings file to your project. You can then easily add configuration settings through Visual Studio. See this link.
更好的是将设置文件添加到您的项目中。然后，您可以通过 Visual Studio 轻松添加配置设置。请参阅此链接。
You could then access your string by using the following:
然后，您可以使用以下命令访问您的字符串：
Settings.Default.MyString;
In addition, settings are strongly typed, so you don't need to do any conversions when you retrieve them.
此外，设置是强类型的，因此在检索它们时无需进行任何转换。
回答by AJ.
Why not make it an appSetting in your web/app.config file?
为什么不在 web/app.config 文件中将其设置为 appSetting？
<appSettings>
<add key="MyLongString" value="This is a really long string value that I don't want hardcoded" />
</appSettings>
Then, in code:
然后，在代码中：
using System.Configuration; //To ease your typing pains
var myReallyLongString = ConfigurationManager.AppSettings["MyLongString"];
回答by Ed Altorfer
To more directly answer your question, the "best practice" would be to use a resource file for any localizable (even if you're not going to localize it) string in your application. This allows you compile-time access to the string and keeps it from being externalized as a separate file to deploy with your application.
为了更直接地回答您的问题，“最佳实践”是对应用程序中的任何可本地化（即使您不打算对其进行本地化）字符串使用资源文件。这允许您在编译时访问字符串并防止它被外部化为单独的文件以与您的应用程序一起部署。
I suggest using this approach; settings are similar, but should not be used unless what you're storing there actually represents a setting. Constants are the other option, but in the case of a long string, I'd stay away from them, just for the sake of maintainability.
我建议使用这种方法；设置类似，但不应使用，除非您在那里存储的内容实际上代表了一个设置。常量是另一种选择，但在长字符串的情况下，我会远离它们，只是为了可维护性。
