Develop Reference

What is the easiest way to generate an App.Config file through pure c# code

I know the easiest way to generate a config file is through visual studio. however the environment my program is going to be functioning in we are going to have several different configurations and the application needs to be able to build the config files on its own. Just curious if there is an easier way than making a large string literal and then copying over to a new file. Thanks for any help.

Not sure what kind of information you want to save in generated configurations.
If you are using only appSettings section which as only key values, then it would be better to generate a JSON file. It is very easy to generate it using newtonsoft.json.
in your app.config file you can keep the path of JSON file and load the settings at app startup if the file is already available.
NOTE:
JSON can also store any kind of complex configurations, you will have to generate the classes to hold those configurations.
Once you application puts value in these objects, serialize it to JSON and keep it in appropriate folder which is accessible to application.
Hope this helps.

Does the .NET binary serializer encode assemby information?

I've been developing a game and part of the process was going to be a custom level tool and file format. I had created a small console application that generated a 'LevelAsset' object which contained only primative data types. The problem arises when I try to deserialize that data within my unity game. I didn't copy any code from my console app and rewrote both the 'LevelAsset' object and Deserialization code from scratch. Yet when I run the game, I get an error saying I'm missing the "Level Tool, version=1.0.0.0" assembly, which is from my original console app. How is this occuring. Is the binary serializer encoding information about the project?
Edit: So upon further investigation it appears that the BinnaryFormatter does indeed include information about the project in the form of a file header. So my new question is now: How on earth do I serialize without headers?

So after a bit of digging its fairly obvious whats happening. BinaryFormatter does indeed encode project information in its file headers. If you want to avoid this you should use binary writer instead.

write / add / rewrite a class at runtime c# unity

in my project i have some sort of level builder that create a new text file and save all my wanted data as readable json string in 1 line.
while the project run in web build or in unity it self i can read the levels from that text file and every thing working great, in mobile builds that doesn't work.
my question is:
is there a way to create or add lines to a class at runtime?
for example write a new string in the class at run time that will stay there after run time is over?

No, there isn't. At least not at mobile platforms.
But you should be able to parse JSON on mobile platforms if you set the Api Compatibility Level to .Net 2.0, not .Net 2.0 Subset and disable Strip Engine Code in the Player Setting.

As #Tijmen said there is no way to change a C# class at runtime. But I see no reason to do so. Instead you should change the JSON string, write it to the file and recreate the level instance.
Looking at your code reveals that you are writing to Application.dataPath which is not writable in iOS player. So it should work when your are using Application.persistentDataPath.
Further on I would refrain from calling the folder Resources as this has a special meaning in Unity.

No there isn't, but you can make an ArrayList instead and put the info from the text file into the ArrayList. Then extract information from the ArrayList.

Importing JSON from ASP.NET server, for JSON.NET

Question:
What is the best way to pull JSON from a .json file on my server, into code, so it can be deserialized into a .NET object?
Details:
I have a file called "backlog.json" saved in my VS2013 Express MVC project. The file was not created by my project - it has been added to the project by doing "Add Existing Item."
"backlog.json" is a collection of json objects. I need to pull these objects from the collection, so I can add to the database my project uses and manipulate with my project.
The project uses .NET Framework 4.5, and I've added NewtonSoft's Json.NET to the project, using NuGet package manager. Once I get the objects from "backlog.json" into my code, I'll use Json.NET to deserialize and manipulate the objects through C#.
For example, something like:
public void AddJSON(EFWorkOrderModelContainer WorkOrderContainer)
{
// Pull backlog.json from C:\Project\App_Data\backlog.json
// De-serialize and parse
}

You can't do string myjson = File.ReadAllText("~/App_Data/backlog.json"); because File class doesn't know how to convert from an application root relative path. You can do string myjson = File.ReadAllText(Server.MapPath("~/App_Data/backlog.json")); or if Server isn't in scope string myjson = File.ReadAllText(HttpContext.Current.Server.MapPath("~/App_Data/backlog.json"));
You should not do string json = File.ReadAllText(#"C:\Project\App_Data\backlog.json"); because that's dependent on where you place the website within your web server, and that's a bad idea.
Yes, MSDN is down right now, so you can't use that to look up the namespace for the File class. But in Visual Studio, if you just type File you can use Intellisense to have it automatically import the namespace for you by right-clicking the File.

I won't mark my own answer as "answered," but a similar way of going about this is actually described on Newtonsoft.com's site. Click here to see the sample... it describes exactly what I was looking for.

Advantages and usefulness of adding an XML file to a Visual Studio 2008 project

What is the advantage of adding XML files to a visual studio 2008 project (windows form app project for example).
Once added to the project, how could I refer to this XML to use it in a class in the same project? In this case, I would be sending it as a query to a web service.

If you want to use the XML in some form, you could mark it as a "embedded resource" in the properties window, and then access it from your code like so:
Assembly a = Assembly.GetExecutingAssembly();
if(a != null)
{
Stream s = a.GetManifestResourceStream(typeof(yourType), "YourXmlName.xml");
if (s != null)
{
String xmlContents = new StreamReader(s).ReadToEnd();
}
}
Once you're done, you have the XML file's contents in "xmlContents", if all goes well.
Marc

I guess the advantage of having your XML reside there in your project (or solution even) is that you can maintain it in VS with nice formatting and even intelli-sense, but then using something like XML Spy or whatever can give you that too.
To refer to it in a class you'll need to ensure you have access to it, and that it resides in a reliable place.
In the past I've used post build events to move the latest copy of the file to where I need it. As Arnshea writes here is another answer, "to the output directory". You can use the "Copy to Output directory" property on the XML file itself to achieve this. Then your classes can use the XML file, knowing it will reside in a reliable place.
You'll need to make sure it's accessible though especially if you're writing back to it. Make sure it doesn't end up "Read Only" - as Source Control system could do to you. Storing these files in a folder under Program Files could also be problematic especially on Vista, where user privileges are (should be) restricted.

If your app needs to load the XML it can be copied to the output directory. Also simplifies use of Setup/Deployment projects...

Another major advantage would be (assuming it's in place--and it should be!) is that you can apply revision control to the XML file.

I guess that you won't be sending the same XML file to the WebService over and over again.
You will want to modify its content every time for that you have XML Serialization.
If all of the above apply then you don't need the XML file, you just need the class that generates the file at runtime. The XML is just the transport, today its XML and tomorrow it might be some other format (JSON).