How to Get MachineName at Compile Time?

[samueltilden]

How can I get the machine name on which the C# code is compiled and
then reference that value within the executable code, as in a "Help --

About" MessageBox?

Preferably embed the answer in a .dll. Worst case would be some pre-
compile step to write it to an XML file that must always be copied
with the assembly.

(The reason is that we have several developers who can push software
to our development box to test, but we need to keep track of which
machine the executable code came from because of possible differences
from source control.)

Thanks!

[ssamuel]

Try this:

1. Create a text file in your project/solution, maybe call it
"MachineName.tx t".

2. Set the file to compile as an embedded resource.

3. Read the contents of the file out of the manifest resources at run
time to populate your message box.

4. Create a pre-build step that overwrites the file created in step 1
above with the current machine name. If you don't already have one,
you could build a short utility that does nothing but dump the machine
name to stdout, then pipe that into your file.

If you're doing plain compiles, that *should* write the compile
machine name into the text file before it's built into the binary as a
resource. I believe that embedded resources aren't re-read unless
something else in the project has changed, so this may or may not work
perfectly if you expect to copy and compile without making local
changes. Also, this will give you... um... let's say "interestin g"
results if you try this with your source on a share.
s}
On Oct 22, 3:13 pm, samueltil...@gm ail.com wrote:

How can I get the machine name on which the C# code is compiled and
then reference that value within the executable code, as in a "Help --

About" MessageBox?

Preferably embed the answer in a .dll. Worst case would be some pre-
compile step to write it to an XML file that must always be copied
with the assembly.

(The reason is that we have several developers who can push software
to our development box to test, but we need to keep track of which
machine the executable code came from because of possible differences
from source control.)

Thanks!

[Nicholas Paldino [.NET/C# MVP]]

One could also write a custom MSBUILD task to write a resource file
before the CSC task is executed.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"ssamuel" <ss*****@gmail. comwrote in message
news:11******** **************@ k35g2000prh.goo glegroups.com.. .

Try this:

1. Create a text file in your project/solution, maybe call it
"MachineName.tx t".

2. Set the file to compile as an embedded resource.

3. Read the contents of the file out of the manifest resources at run
time to populate your message box.

4. Create a pre-build step that overwrites the file created in step 1
above with the current machine name. If you don't already have one,
you could build a short utility that does nothing but dump the machine
name to stdout, then pipe that into your file.

If you're doing plain compiles, that *should* write the compile
machine name into the text file before it's built into the binary as a
resource. I believe that embedded resources aren't re-read unless
something else in the project has changed, so this may or may not work
perfectly if you expect to copy and compile without making local
changes. Also, this will give you... um... let's say "interestin g"
results if you try this with your source on a share.
s}
On Oct 22, 3:13 pm, samueltil...@gm ail.com wrote:

>How can I get the machine name on which the C# code is compiled and
then reference that value within the executable code, as in a "Help --

About" MessageBox?

Preferably embed the answer in a .dll. Worst case would be some pre-
compile step to write it to an XML file that must always be copied
with the assembly.

(The reason is that we have several developers who can push software
to our development box to test, but we need to keep track of which
machine the executable code came from because of possible differences
from source control.)

Thanks!

[samueltilden]

Thanks, I know how to do some of what you write, except:

#2. How do I " Set the file to compile as an embedded resource?"

#3. How do I "Read the contents of the file out of the manifest
resources?"

#4. I now have a pre-build step that says "hostname MachineName.txt "
but it puts the answer in {project}/bin/Debug directory. Should I
have the pre-build step say "hostname ..\..\MachineNa me.txt"? or
some other location. I guess question #4 is related to #3.

Thanks

[ssamuel]

#2. How do I " Set the file to compile as an embedded resource?"

This assumes you're using Visual Studio: click on the file in the
solution explorer, and set the Build Action in the properties.

#3. How do I "Read the contents of the file out of the manifest
resources?"

#4. I now have a pre-build step that says "hostname MachineName.txt "
but it puts the answer in {project}/bin/Debug directory. Should I
have the pre-build step say "hostname ..\..\MachineNa me.txt"? or
some other location. I guess question #4 is related to #3.

Yes, they're related. You probably want the text file in the folder
where the project files (.cs, etc.) are stored rather than the output
directory. The key is to make sure that you're writing the machine
name to the file that you're compiling into your assembly. If you're
using VS, you can easily get a handle to it in the pre-build with
macros.

To load a file embedded in the manifest resources, do something like
this:

new
System.IO.Strea mReader(myObjec t.GetType().Ass embly.GetManife stResourceStrea m("Namespace.Fi leName.ext")).R eadToEnd();

It's probably useful to have something like Lutz Roeder's Reflector
(http://www.aisto.com/roeder/dotnet/) if you don't already. It's free,
I'm not affiliated with them, and there are probably other tools that
do the same or more. That will allow you to inspect the assembly
you've created to ensure that it contains the resource as well as to
determine the exact string name. Keep in mind the name must be fully
namespace-qualified. Also, the code I wrote above is an example only
and leaves you to deal with things like disposing of resource handles,
exception handling and so on, where necessary.
If you're not using Visual Studio, Mr. Paladino's reply above will
probably yield better results. I've used NAnt but not MSBUILD, so I
don't have much to offer along those lines. Even if you are using VS,
you may be one of the many people who find something like MSBUILD more
convenient than VS. I'd assume you'd somehow need to tell csc or some
linker that you want your text file or other data compiled and
embedded.

Resource files are another perfectly good way to do this. I prefer
this way most of the time because I find it easier. If you're used to
using resx files and so on already, by all means, do it that way. The
general solution should still stand.
s}