Develop Reference

Merge Conflicts and Poor UI with .Net Resource Strings

Resource strings are quite irritating.
You have to copy the text into Notepad++ to edit them
Scrolling through large strings is near impossible
When you press F12 on a resource string reference, it brings you to the proxy to the resource store, but no way to edit, nor can you see the full text of long strings.
As more developers fill the list of resource strings, merge conflicts occur more and more on the XML resource files.
Is there a way to stop merge conflicts in the XML resource string files? Is there a better way?

You have to copy the text into Notepad++ to edit them
Visual Studio also provides an XML editor view for resource files. I use this almost exclusively over datasheet view. Give it a try.
Scrolling through large strings is near impossible
Probably easier in XML view.
When you press F12 on a resource string reference, it brings you to the proxy to the resource store, but no way to edit, nor can you see the full text of long strings.
I just use ctrl+F and type in the resource ID.
As more developers fill the list of resource strings, merge conflicts occur more and more on the XML resource files.
Merge problems are greatly reduced if all developers ensure that resources are added or inserted to the file in alphabetical order. We wrote a script to do it and put it into the automated build.
Also, consider organizing your resources into separate files for different purposes, e.g. control labels can go in one file and large text sections can go in a different file. This will reduce contention as well.

Yes, there is - code.
Create a separate static class, I like to suffix "Queries" if it's full of SQL, or "Resources" if it's more general.
In C#, you can use #"", that's enough, but the more recent $#"" is nice if you want to interpolate.
Example:
public class ApplicationStructureCacheQueries
{
public static readonly string ChangeOverNew = $#"
delete from ApplicationStructureCache
insert into ApplicationStructureCache
select * from #NewApplicationStructureCache
";
}
Code Control works very well with line-based coding languages (rather than structured data with multi-line associations - XML). You get the full power of your coding language to work with your strings, including inheritance if you need to (but make it a singleton object, instead of static reference), or perhaps an interpolating function, so it's nice and typesafe and cohesive.

Using Resources (resx) Inside a ClassLibrary, that can be changed without recompiling

I need to make a ClassLibrary, to contain different Resource Files (resx). This needs to be done, so I can reuse these resources on multiple projects.
After reading for quite a while on how to achieve this, I'm still nowhere near close to an answer.
Note that i need to achieve this in a way that I don't have to recompile the proyect if I want to change a value
Is there a simple way to achieve this that I'm missing?

Hate to be the bearer of bad news, but I'm afraid you're trying to use RESX files for something other than what they're designed to do. RESX files are compiled into .resources files, which are then embedded into the assembly during the build. In other words, if you don't recompile, you won't see any changes that are made to the resx file reflected in the module.

The benefits of RESX files extends far beyond providing compiled cultural/language text tightly coupled to a deployed solution. They have the potential to provide a simple and flexible set of content managed outside the software development process. Some views here:
What are the benefits of resource(.resx) files?
Yes you can work with your RESX files without having to compile them. See here:
Edit ASP.NET MVC 3 resx files in deployment server without recompiling
Yes you can share RESX files between different projects and even roll your own resource manager. You can maintain alternate sets of resources, serving up alternate content depending on for example the user context. I have been involved in a project where we implemented something along these lines to great affect, in my case the solution was used to provide white labeling. Some detail to get you started here:
http://msdn.microsoft.com/en-us/library/aa905797.aspx

Embed serialized data into executable

I'm currently working on a small project where I have a list of lists of objects, which I need to store between program executions. The scale of the project is in my opinion not large enough to start developing an external DB-solution, so I would like to store the data inside the executable, so the end-user does not have to keep track of multiple files. Is this possible at all? I've been thinking about embedding the file as a resource, but as I have read, it is not possible to edit this resource file without recompiling the project, so this is not a solution. Alternatively I have read about Alternate Data Streams, but I don't know if it is a good idea to edit the executable this way?
So all in all I need the executable to store data between executions, without the need for managing other files.
I hope you are able to help me.

I believe Application Settings are the way to go here.
More explained at Best practice to save application settings in a Windows Forms Application

c# help needed for application update

Hello guys I think the question i asked in the previous post is unclear OK fine. i am explaining in brief.
for example.
I have a form where i have placed one textbox and command button.
I have fired a event when i click the button the text under the textbox change to "hello" ok fine.
what is my problem is..
the application is created and I published ok.
After some week I thought I want to update my application. where in the place of "hello" I want "hi". I know that we can compile the whole project and publish it.
but I don't want my whole application to be updated.
for example.
What antivirus company do they have a definition file where they only update the definition file not the whole application. after the update it applies to whole application.
I want my application also to do same process like antivirus company do.

You should read that "Hello" from a content file (XML). Then you can just push out the new file.

Use a configuration file. You can add an application.config (or if you're developing a web app, web.config) file to your primary project. Within this configuration file, you can define AppSettings (which are built-in, usually simple and atomic string or number fields that the application will need), ConnectionStrings (which specifically provide information applications will need to connect to a database), or custom configuration sections (used for more complex, related sets of data that are loaded into custom classes you define, such as a basic company profile). Within your code, you access AppSettings by using the static ConfigurationManager.Appsettings[] collection; you tell it the name of the setting you defined in the file, and it returns the value (or null, if it can't find the setting you defined).
Related, but different, is the use of Resource files. Resource files usually contain a dictionary of location-specific data used by the UI, such as text strings, icons and images. Actual resources can be compiled into one big file, or resource files can be a list of paths and filenames to the actual resources. You can use resource files to create different "skins" for your application to be used by different companies by referencing images to use for UI elements, or to translate labels and other text on your application's UI. Resource files are accessed through a ResourceManager; you tell it where the resource file is, and it will load the information into a similar "dictionary"; you then tell it the name of the resource and you get the resource back.

For your specific question, I'll answer the same thing as Henk. But, I think that your real question is "How I do create patch in .NET".
You can check this link:
How can I patch .NET assemblies?

You could design your application to use plugins. This way you only have to update a plugin and not the whole application.

if you want to create a patch for asp.net application , first of all , you have to deploy your project with Web Deployment Project.
then choose Create a separate assembly for each page and control output in output assemblies tab and re-build your solution .
the result of deployment is bunch of DLL which mapped to each page or control.
Now if you changed one page's data (in code behind) , you need to deploy your project again but in this case you can just upload the changed dll file.

how to store settings for deployable c# application?

I want to store settings for my C# application, such that default setttings can be easily shipped with my binaries and the end-user can change them using a simple text editor(or in some other simple way).
I seem to face several alternatives : a .config file, .settings file or a .resx file. What are the pros and cons of these?
Edit1: End-users are computer professionals mainly, so editing these files should not be much of a problem.
Edit2: The settings are something like connection strings, and some other parameters (mostly one-time stuff). Building some kind of GUI/API for changing them is not really an option. Also my application will not edit any of these values, so persistence through code is not required.

Yes, Project + Properties, Settings tab was designed to do this. Add your settings here, change the Scope to Application. That generates a app.exe.config file in your build direcctory, deploy it along with your EXE. Use Properties.Settings.Default.SettingName in your code to obtain the setting value. Your user will normally need admin privileges to edit the .exe.config file on the target machine to change the setting value.
The small print: settings do not work well for DLL assemblies, you have to merge the .config files by hand. When using the debugger, settings are retrieved from the app.vshost.exe.config file.
The .settings file is a helper file used by the IDE, ignore it. .Resx files store resources, they get compiled and embedded in a binary form in an assembly. They are not editable by the user.

I think you can have two ways of doing this.
For regular users, you can make a custom GUI that will make it simple for them to use.
For advanced users, they can edit the configurations using a text editor if it's stored in a text file (ini file, config file, etc..) or you can make an API.

The .settings file is typically used for user-specific preferences and configuration information (whereas the .config file is used for global settings for the application or anything that modifies the .Net runtime. Simply putting parameters in a .config file can alter the behavior of your application even without you writing a single line of code for it).
Check out the Settings article on MSDN for more: http://msdn.microsoft.com/en-us/library/aa730869(VS.80).aspx

Since the file will be modified by the users, I think using app.config is not a good idea. What if they break the file structure? Or set an invalid value? Probably your application will crash directly.
One of the solutions would be to use a custom XML file. You will then validate it when your application starts. XSD will probably be the more elegant way to do it, but you can also parse it directly and validate it in code. If the file is invalid, instead of crashing, you will try to solve the problem, and if impossible, display a pretty error to the user, explaining that there is an error in XML at line n, position n, which is [error description here].

If the end user is really going to be editing them, I'm not sure I would want them editing my app.config file.
You have another couple alternatives that you haven't included. You could use an old-school .INI file that is simpler for an end user to understand. You could also use the registry. I would recommend the INI file, unless your users are very savvy, in which case use the .config file.

The answer depends on the deployment method. For instance, if you are using ClickOnce and offer updates, you might encouter problems using Application Settings.
I believe the best way to go is to create a GUI, something that is most certainly suitable for novice users. Given that you already excluded that option, use John's suggestion (ini files).