Develop Reference

Custom WMS Service

I'm doing an program, which is running on an local system, with no internet access. Is it possible to create my own custom Web Map Service (WMS) server, using C#. I no that there are free open source system's. But i like to have full control.
Thanks Morten Starck

That is very possible, but you might be in for a headache or two before you are done. The implementation specification and more is available from the Open Geospatial Consortium at the url below.
http://www.opengeospatial.org/standards/wms
It's quite a large specification but you might be able to get away with implementing only the parts you really need and leaving some of the more specific stuff out. You will of course also need to parse and render the map data from some source which might be your largest problem (for which I really would suggest you have a look at SharpMap, http://sharpmap.codeplex.com/ instead of rolling your own).

Seeking Advice on Design for Multiple Users working in the same file

I am at the earliest stage of writing a desktop application for use by multiple users. I am looking for advice on what is the best way to approach this.
The Spec
I will persist my Model in a file which would often be used on a mapped network drive. (It is for the design of roadways and other linear features like railways and streams.)
The various end users need to be able to connect to and edit the file simultaneously. For example, Billy Bob is working on the road named US321 while Rupert is working on I40. The models for each road live in the same file. End users can "claim" any road name, in which only the claimant can edit the given road. Rupert can't edit US321 while Billy Bob has it claimed, but Rupert can read US321 for reference. Once a user is finished editing the road data, he can release the claim and someone else could edit it.
Limitations on Serialization?
My understanding of Serialization is quite limited (see my profile). But it looks to me like there is a one-to-one correlation between objects and serialization files. So if I use serialization to implement this, it would not be possible to claim just a part of it nor would it be possible to update only a part of it. (Is this correct? If not, then I can use Serialization, right?)
The Solution I am Considering
I am considering using SQL Server Express, and I am interested in the community's warnings, corrections, or affirmations on this.
The end users would not have to know that I am using SQL Server Express in the background. (I would even change the file extension to something suitable to my app.) I would load roads into a list, and each road would be "claimable". Claiming a road would mark it in the database for the other instances of the app to react to accordingly, kind of like it is a shared MS Excel file that multiple people can edit simultaneously, but (in the analogy to Excel) being able to lock individual worksheets.
[Edit] See Micah Armantrout's very informative response, below. So now I am wondering about using Microsoft Access as the intermediating db app.
[Edit]
Conclusion
Thanks to everyone for their helpful answers and comments. Micah's answer was very helpful since I did not realize I would be limited to the file being controled by only one server. Although it makes perfect sense now, I had not anticipated it, and if I had gone that route, I would have run aground on it after many hours of working in that direction.
When I first read urbadave's idea, I dismissed it as something I had already considered and not liked. But after thinking it over, it is clearly the simplest approach. I just use a directory like it is a file, but with user-transparency to my my top level sub-objects. But there clearly is an appeal to having my whole model be encapsualted into a single file.
So this is what I have decided to do: Start with just writing to a directory, just as urbadave suggests. Then later test out putting it in a zip directory and using the ZipPackage class to pluck out and insert the individual serialized files (or XML files -- another decision I have to make some day).
Paul

SQL server will work for what you are looking for but if your going to have multiple users you need to have a machine setup to be a server. It will not do you any good to have sql server express installed on each machine It might be one of the users machines or an actual server with SQL server express you are going to need to set it up to be accessible outside of a current machine to do this follow this tutorial.
If you are using anything past windows XP SP2 you will need to open up the ports of the firewall follow these instructions this is also talked about in the link below.
http://blogs.msdn.com/b/sqlexpress/archive/2005/05/05/415084.aspx
As far as sharing data I mean seeing other peoples work. If you are not wanting to install sql server on a server you can use MS Access I would refer you to a article on which one to use when
http://www.techrepublic.com/article/should-you-use-sql-server-express-edition-or-microsoft-access-for-your-small-business-applications/6140859

While I have access to a nice database at work, most of my personal programming does not use a database. One of the tricks I've used in the past is that file extensions are meant to carry meaning. In your case, you can exploit file extensions to indicate claims and control writing to the master file.
You're right, you would want to serialize each road object to its own file. The Master File would be the serialization of a collection object that holds all of these individual road objects.
The users select and open these road files. Before opening the file, the user's app re-names the file, adding an extension (perhaps the user's id). This way, you can use directory scans to find claimed and unclaimed files.
The master file is only written to when the user releases their claim on the road they are working on. The user's app opens all the road files, assembles a master object using the road objects and then serializes this object into the master file. When finished, the users app releases the user's claim on the road file by renaming it.
Before writing to the master file, the user's app renames the file, indicating it is about to be written to. If an users app needs to write, it can check to see if the file is renamed, and wait for the file name to be restored to a writable name.
This is a sketch of how I would attack this spec. Good luck.

Implementation of industry specific resources

We have a program that is used in one specific industry and has strings that are specific to that industry. We now have the situation where it can be used in another industry and we want to customise the strings for that industry without duplicating our code base.
The problem space appears very similar to localisation. Are we going to have a separate resource assembly for each industry? If so when would we choose which assembly to use, could we do this at install time or would it need to be at compile time?. How do we keep the separate resource assemblies synchronised, so that the same keys to messages appear in each one?
What is the best way to do this?

Let me re-phrase it: you have an industrial application which could be used in various industries and the only things that are different are resources (that is strings, layout, maybe images and sounds). The other code stays the same.
In such case your problem is not just similar it is actually identical to Localization. And as such you can use Satellite Assemblies.
Now, it is up to you if you want to package such created applications separately or distribute one application with both problem spaces.
The first seem more realistic scenario to me - you would need to decide on which .resx file to include at compile time (i.e. during project preparation you would overwrite existing resources with problem-space resources and then proceed with compilation, that should give you different flavors of your application; I would also modify their names in such case).
The latter would require you to manually instantiate ResourceManager at runtime to read from valid satellite assembly - it could be based on some configuration file. It means more work (you would need to actually modify your code) and you will end up distributing both flavors of your application at once, that is you won't have control over how your customers will use it. From the business perspective it could be a little dangerous.
EDIT (Note to self: read whole question carefully)
Somehow I managed to miss install time vs. compile time. I believe compile time is the answer because of the same reason I gave in config-driven switch section: you would package the resources and you won't have any control on how customers use it. Some clever guy would figure it out, that is for sure.

I would recommend having a properties file with key value pairs. Where you currently have industry specific strings, replace them with calls to the properties file. Obviously you would cache these strings in some container. I don't know the C# container - Java would use java.util.Properties.
aerospace.props:
INDUSTRY_NAME=aerospace
INDUSTRY_START_YEAR=1903
manufacturing.props:
INDUSTRY_NAME=manufacturing
INDUSTRY_START_YEAR=1600

Creating an international website

The question might sound weird, but I am planning to create a asp.net website, which when fully done, will ideally cater to all countries.
I am currently in the architecture phase.. and is there anything that I should keep in might when doing this?
like
saving all datetime fields in utc
using user's timezone to display all time related data
all labels in the website to be localizable
is there anything else??
thanks,
Chris

A few additional points:
Some languages read from Right to
Left (Hebrew for example), which
will affect your UI.
Make sure your datastore supports
unicode (NVARHCAR vs VARCHAR).
Provide an easy way for translators
to contribute content. Usually means
creating a Data Driven Resource
Provider.
Internationalization and Localization is a good place to start.

You should think about how the localization process will take place. I assume you are not a native speaker in all languages you want to use for your application.
There are several approachs on how to address this: For example, there are companies that specialize in localization, meaning you give them an excel sheet, or an xml file.
You should also think about, where do you want to have all these localizations. Do you only want them in your ASP.net application, meaning in only one place? Then the resource file will be your way to go, because they are easy to handle and easy to send to localization studios.
But if you want to use the localizations in more than one place, you need to store them in a web service or in a database. Keep in mind that using localizations across multiple plattforms (e.g. web site, administrative tools) will force you to write import/export functionality for the used tables. (Because you won't give the localization company access to your database)

I would start by looking here: http://msdn.microsoft.com/en-us/library/c6zyy3s9.aspx.
I also guess you are working on doing a SQL database. If that is the case look at things like using nvarchars.

Where to store application settings

I am creating an app that reads some info from a scale via RS232 serial port connection. There are a couple of types of scales that are in use, so I would like to store specific settings for the scale in my program. What is the best way to do this? Via app.config? Or should I put the values in a database?

It really depends on where will these configurations be used?
If you are working on a distributed huge system, which means these configurations are probably shared/used by other systems. You'd better store it in the database, with a common protocol which other related systems agree with.
On the other hand, if these configurations are used for a small application, storing them in a config file(or an xml file whatever you like) is suggested because, you don't need a gun in order to kill a mosquito.

app.config would be the easiest option for you. I think a database might be a bit overdoing it for just some settings, but if you wish to use something outside of what is offered by VS (namely app.config) then you could always whip up a quick custom XML settings file. All depends on what you wanna do with it and how comfortable you are with the other technology.

Is the information chaging ? that means when you ran ur app , would it be the case that information is updated ?
if the information is static and do not change frequetly , you can store in the app.config.
or in a xml file and you can read that information lately.
but if the information is dynamic then you need to create a model and expose scale information through model's peroperty.

Do not forget the registry.
Use the registry when:
You need your settings to be accessible for a domain admin
you need to secure some settings (using Windows security)
(You can make some settings read-only)
There are a lot of small settings that change very often

If it's simple and straightforward than app.config is the way to go - you don't need to set up a database and you get to use simple built-in interfaces.
If you choose to go with a database check out mysql for a simple file based database that has a simple deployment scheme.