A question regarding built-in resources

[Michael B. Trausch]

I am hoping that someone will help me to understand why the CLR
provides support for embedding arbitrary resources into executable
files. Most of the time that I find that I need to bundle data with an
application for deployment, I find that the data that should be
bundled also sometimes needs to be easily replaced in-between
application deployments.

Using a .dll assembly to bundle data is certainly possible since it'd
be replaceable---as long as it's not strongly named, as I understand
it. Also, as I understand it, you cannot update the resources (since
this would also defeat the purpose of strong named assemblies) and that
means that using small embedded databases which are flat files and
embedded in assemblies is probably not a very good idea.

What I typically do is for collections of small, static files which may
need to be updated is just bundle them in a tar archive which has an
associated digital signature which is generated with some form of
OpenPGP (usually GnuPG). This way, the signature is easily verified
against the file and when the file is updated, so is the signature
(which is of course contained in a separate file). If the signature
doesn't match the file, then I know that the file has been altered,
and can throw an error.

For resources like xBase database files or SQLite databases, I rely
upon trusting the user to not modify these files unless they know
pretty well what they're doing (and of course, if they modify them and
something breaks, that's their doing not mine).

In any case, I am just wondering what the typical use case for
embedding resources into assemblies is, and why.

--- Mike

 

[Ignacio Machin ( .NET/ C# MVP )]

I am hoping that someone will help me to understand why the CLR
provides support for embedding arbitrary resources into executable
files. Most of the time that I find that I need to bundle data with an
application for deployment, I find that the data that should be
bundled also sometimes needs to be easily replaced in-between
application deployments.

Hi,

A little out of topic, why you do not want this thread to be archived?

 

[Ignacio Machin ( .NET/ C# MVP )]

I am hoping that someone will help me to understand why the CLR
provides support for embedding arbitrary resources into executable
files. Most of the time that I find that I need to bundle data with an
application for deployment, I find that the data that should be
bundled also sometimes needs to be easily replaced in-between
application deployments.

Using a .dll assembly to bundle data is certainly possible since it'd
be replaceable---as long as it's not strongly named, as I understand
it. Also, as I understand it, you cannot update the resources (since
this would also defeat the purpose of strong named assemblies) and that
means that using small embedded databases which are flat files and
embedded in assemblies is probably not a very good idea.

What I typically do is for collections of small, static files which may
need to be updated is just bundle them in a tar archive which has an
associated digital signature which is generated with some form of
OpenPGP (usually GnuPG). This way, the signature is easily verified
against the file and when the file is updated, so is the signature
(which is of course contained in a separate file). If the signature
doesn't match the file, then I know that the file has been altered,
and can throw an error.

For resources like xBase database files or SQLite databases, I rely
upon trusting the user to not modify these files unless they know
pretty well what they're doing (and of course, if they modify them and
something breaks, that's their doing not mine).

In any case, I am just wondering what the typical use case for
embedding resources into assemblies is, and why.

It depends of your needs. You have the feature, you use it the way you
want.
I have used it to store images that my application use. I think this
is the most common case.
In another situation I have stored data files (shape files from an GIS
application)


In any case, it's up to you to decide what to include.

 

[Michael B. Trausch]

A little out of topic, why you do not want this thread to be
archived?

I set the no archive headers on all posts I make to Usenet. This
doesn't mean that they're honored; while Google Groups will honor the
request to not archive the post, other sites that "leech" Usenet don't
do that.

In any case, the thread should be archived just fine; it will only be
my posts that aren't (if honored, anyway). As to why? No reason in
particular. For places that honor it, they'll save storage costs, for
places that don't honor it, oh well, I suppose. They should, since its
meaning is well-known.

Anyway, anything worthwhile that I say---any answers I give that are
agreed upon, or any questions I ask that get answered---will get
propagated into a thread, where there are several people that do _not_
set the header... so the information is preserved directly by way of its
perceived worth by those replying to it.

Does the no-archive header bother you?

--- Mike

 

[Michael B. Trausch]

It depends of your needs. You have the feature, you use it the way you
want. I have used it to store images that my application use. I
think this is the most common case. In another situation I have
stored data files (shape files from an GIS application)

So, mostly static data that you figure your app won't need changed? Do
you strong-name such assemblies so that they aren't replaceable?

--- Mike

 

[Michael B. Trausch]

I can't speak for Ignacio, but it bothers me. Your answer that
"anything worthwhile will get propagated into a thread" is deficient,
in that it assumes that you are the only person using no-archive. In
general, any behavior that is defended with "I'm the only one doing
it, so it's okay" automatically implies that if everyone were doing
it, it wouldn't be okay. And any behavior that wouldn't be okay if
everyone would do it should not be done by anyone. It's the classic
"overfishing the pond" dilemma.

It was one answer among several. I don't have to assume I'm the only
person using No-Archive for that to remain valid, anyway. There will
always be a substantial number of people on Usenet who do not use the
No-Archive header. Further, even if that weren't the case, the
Internet is a decent amount larger than that. Good things on the
Internet make it across multiple segments of the Internet, carrying
over into the Web, or sent in email messages. This is how it has been
for as long as the Internet has existed---way before there were ever
archives of anything.

More generally, you cannot at all rely on your own text being quoted
to provide context in archives. Not everyone quotes a post, or the
code, or both. Unless you have a VERY good reason for your own post
to not be archived, you should not be setting the no-archive field.
Even when it is set, it should be on a case-by-case basis, and this
should be a rare event.

You cannot easily set arbitrary headers in many MUAs, and in some MUAs
you can't set arbitrary headers at all. If a person wants their posts
to be not archived, I don't see a problem with that. There are many
reasons---many of which would really be none of anyone's
business---that one might want to use the headers to request (keep in
mind that's all it is, a _request_) not archiving the post.

There is nothing that says that the request has to be honored. I know
of at least a small handful of Web sites that refuse to honor the
request. Now, while someone else might have a problem with that, I
don't. The information is still out there. There is just no need for
it to be pointlessly duplicated in more than a few places. In fact,
the only service I know of that actually honors it is Google Groups,
which is fine by me. GG is today's extension of the eternal September,
and I've probably seen _one_ meaningful post come from there.

For you to not allow your own posts to be included in the archive is
to say to the entire community "I want to take advantage of this
discussion, but I do not want my own contributions to be available",
which is a very selfish approach. Even if you intend to be selfish,
you can't expect others to think kindly of that, and if you didn't
intend to be selfish you should be _especially_ wary of acting that
way.

I don't prohibit my posts from being including in any archive. (Do
note that there isn't a "the" here; there are _many_ archives of
various segments of Usenet all over the place, some of them with really
nasty "forum" frontends.) If I wanted to do that, I would place each
of my messages under a restrictive copyright license permitting use
only under certain circumstances and for certain durations of time. It
is unfortunate that you feel that I am making a statement that I am
not; setting X-No-Archive, for starters, is nonauthoritative, and says
_nothing_. It doesn't say "I want to take advantage of this
discussion, but I do not want my own contributions to be available," as
you put it; it says "I desire not having my posts archived by default,"
without alluding as to why. Anything beyond that is assumed---it's
speculation.

Is setting X-No-Archive a selfish act? I don't believe so. It's
really no more selfish than setting a header "X-No-Print" or
"X-Redistribution-Prohibited" or "X-Content-License" or "X-Vote-Obama"
or anything else you could think of to add to the headers you transmit
in your messages. I don't see it as any more selfish than obscuring
one's email address in Usenet headers. I _might_ care if someone were
going around attaching kilobytes of extra headers that made it a PITA
to actually *use* a newsreader.

FYI, if you've an actual honest-to-goodness problem with the
X-No-Archive header, you may want to use a service like Motzarella. My
XNA-posted messages are still available there. I should think that any
sane Usenet server accessed over NNTP would act in the same fashion.

In any event, if it really is such an issue, I will disable it. It
should take effect with either this or the next post I make. Feel free
to let me know privately if you continue to notice new posts after this
from me which still have them set, but that shouldn't happen.

--- Mike