Project Assembly Name Change Problems

  • Thread starter Thread starter Tracks
  • Start date Start date
T

Tracks

Hi all,

After 20 years I am now on version 10 of my program. Now using VS2008 with
VB.Net. You would think I could figure how to change the name?

I want to change my application name from MyAp9 to MyAp10 (ie the compiled
name should be MyAp10.exe). So I changed the project name, and in
settings-application I changed the assembly name and root name all to MyAp10.
I change names in Assemby Info dialog and the I change all the version
numbers to 10 etc. Now when I run my ap I get the following error:

Unable to find assembly 'MyAp9, Version=9.0.7.0, Culture=neutral,
PublicKeyToken=null'.

On the following lines of code:

Dim FileStream As New FileStream(NewName$, FileMode.Open, FileAccess.Read)

Drawings(DrawingIndex) = DirectCast(formatter.Deserialize(FileStream),
DrawingType)

If I change the assemby and root names back to MyAp9 it works.

What am I missing? Is the name of the app in the serialization setup things
somewhere? Where else to you change names/versions?

Thanks, Tom

PS Why is it so hard to do something so simple?
 
Tracks,

Why do you do such a simple thing so difficult, you can simply change the
assembly name.
If you want to change the Exe name then have a look at he Project
properties.

Cor
 
I guess my problem description was not clear?

When I change the assembly name in project properties (application tab) from
MyAp9 to MyAp10, I start to get an error on a directcast file read saying it
cant find MyAp9 (ie it is looking for the old name somehow):

ie This code:

Dim FileStream As New FileStream(NewName$, FileMode.Open, FileAccess.Read)

Drawings(DrawingIndex) = DirectCast(formatter.Deserialize(FileStream),
DrawingType)


gives this error:

Unable to find assembly 'MyAp9, Version=9.0.7.0, Culture=neutral,
PublicKeyToken=null'.


Since I changed the assembly name to MyAp10, why is it looking for MyAp9? If
I change the assembly name back to MyAp9 it reads fine.

Tom
 
Select solution , right mouse , select "Clean solution" , then select
"rebuilt solution"

HTH

Michel
 
Michel,

Thanks, but that does not seem to work, still has the problem.

I changed the Assemby name (and root namespace) on the Properties page to
MyAp10 (from MyAp9- not the real name of course), then I "Clean", then
"Rebuild" solution as you suggest and still get the same error from
directcast looking for MyAp9.

Its a big ap with lots of forms and mods and the problem code line is in a
seperate module, if that makes any diff.

After all this, I change the assem/root names back to MyAp9, works fine.
Drives me nuts.

I would just leave it, but I want the compiled name to be MyAp10.exe, and
this only seems to be set by the assembly name?

Tom
 
Tracks,

It is hard to say, but what I do in these cases is searching (Find) for
MyAp9 in all files.

Cor
 
I am just getting into .Net but it appears the line of code that throws the error is deserializing
an object. Does the serialized object contain a reference to the prior assembly name?
 
Stewart Berman said:
I am just getting into .Net but it appears the line of code that throws the
error is deserializing
an object. Does the serialized object contain a reference to the prior
assembly name?
Click to expand...

Open your file that you are deserializing with notepad and see what
application information is being serialized. I haven't used serialization
for a while but I know if you change things it complains.

LS
 
Stewart,

Yeah. No, the serialized part is just a big array of arrays with user
defined types. I am fairly sure it is nothing to do with the data being
read. As far as I know, I have not hard coded the name anywhere.

I have searched the project for the old project name and dont find it.

I wondered about MYSETTINGS which I use. I have used SYCHRONIZE on the
Project Properties - Settings Tab with no change.

Bottom line - the program starts fine if I just skip the file read part, so
dont think it is anything but the serialization reference or the direct cast
ref. Anyone know where is this defined? What reference file?

Thanks,

Tom
 
Tracks said:
Stewart,

Yeah. No, the serialized part is just a big array of arrays with user
defined types. I am fairly sure it is nothing to do with the data being
read. As far as I know, I have not hard coded the name anywhere.

I have searched the project for the old project name and dont find it.

I wondered about MYSETTINGS which I use. I have used SYCHRONIZE on the
Project Properties - Settings Tab with no change.

Bottom line - the program starts fine if I just skip the file read part,
so
dont think it is anything but the serialization reference or the direct
cast
ref. Anyone know where is this defined? What reference file?

Thanks,

Tom
Click to expand...

Again , if you look at the file you will see information about the assembly,
the version of the assembly, the object name etc. Since you have changed
some of the information (assembly info for .exe) it cannot find MyAp9 so it
cannot deserialize the file.

LS
 
Ok, I see, finally, and yes there it is in the data file, the "old" name of
the program.

I had no idea the name was being written in there! Heeuuyuk. And then I have
to admit I dont really understand any part of it beyond using the required
lines shown to read the data file that I wrote with some other lines of code.
In fact, I spit at it, spit, spit! How dare you do this to me Microsoft!

Dont get me wrong, I LOVE Visual Basic :)

There it is, the old name, but, I dont see why the name of the program has
anything to do with it? Sorry. Dumb old me. Thought I could write a data file
and turns out I can, but then I cant change the name of the program?

Guess I am off to read the directions for a while.

Thanks,

Tom
 
As I understand it, this is one of the side effects of allowing multiple versions of an application
to live on the same machine. Just as the Assembly knows which versions of a DLL to use, serialized
objects need to know which version of an Assembly understands them. Consider what would happen if
you changed the definition of the object you serialized between version 9 and 10.

Again, as I understand it (and I am sure many folks will correct me if I am wrong) if you want to
use a serialized object across multiple versions you should put it in a separate assembly. That way
both version 9 and 10 of your application could reference the same assemble version of the object.
 
Stewart,

Hmmm. I see. Sort of. Welp, I have always managed old file versions myself.
I keep the version in the file, and my code knows how to handle them all. My
problem is I did not know serializing did this, thought I was just writing a
file, as in VB6 or before. Now I have thousands of customers using my
software from last years to write their own data files and I cant update the
name anymore. Seems very strange to me. The user defined type is defined in
the new program version .exe, what more does VB need? Had I known then I
would have made the assembly name MyAp with no number and then not had the
name change problem.

Again, I dont understand it and dont try to unless I have to and even then I
still dont know enough to just learn it on my own.

Here is the thing, I can read the version number I wrote in the file by:

Version = DirectCast(formatter.Deserialize(FileStream), Single)

since the version is a single and first number in the file. But, it spits up
on the user defined type (DrawingType in the code sample below) that defines
the entire file structure, even though the type is defined in the new version
..exe. So, why does it have to look for the name of the assembly from the file
and look for some other .exe? Why does it not use the type defined in the
current version .exe where the line of code that is executing is located?
Goofy to me. I mean I see what you are saying, I just think it is dumb and
wish someone had told me...

Thanks again,

Tom
 
Tracks said:
Stewart,

Hmmm. I see. Sort of. Welp, I have always managed old file versions
myself.
I keep the version in the file, and my code knows how to handle them all.
My
problem is I did not know serializing did this, thought I was just writing
a
file, as in VB6 or before. Now I have thousands of customers using my
software from last years to write their own data files and I cant update
the
name anymore. Seems very strange to me. The user defined type is defined
in
the new program version .exe, what more does VB need? Had I known then I
would have made the assembly name MyAp with no number and then not had the
name change problem.

Again, I dont understand it and dont try to unless I have to and even then
I
still dont know enough to just learn it on my own.

Here is the thing, I can read the version number I wrote in the file by:

Version = DirectCast(formatter.Deserialize(FileStream), Single)

since the version is a single and first number in the file. But, it spits
up
on the user defined type (DrawingType in the code sample below) that
defines
the entire file structure, even though the type is defined in the new
version
.exe. So, why does it have to look for the name of the assembly from the
file
and look for some other .exe? Why does it not use the type defined in the
current version .exe where the line of code that is executing is located?
Goofy to me. I mean I see what you are saying, I just think it is dumb and
wish someone had told me...

Thanks again,

Tom
Click to expand...

While your serialized information is indeed stored in a file, it is a
structured file so that it can be deserialized.

To do this it uses Reflection which in turn needs to know where the assembly
is that contains the meta information for the object. This is so that any
objects with the Serialization() attribute can be serialized/deserialized.

To deserialize an object it pulls from the file the object name and the
assembly with the information. It would then create a new object using the
default construtor. If you don't have a default constructor (a New with no
parameters) it will fail. It then creates the object and from the file
fills in the properties. To do this it must know the structure of the
object and it gets that from the meta data found in the assembly.

I think you may have the wrong approach to versioning as well. The assembly
will allow you to store the version information in the assembly. I have
never seen an application which changes the assembly name for each version,
the only change (other than functionallity) is to change the version
information.

LS
 
This is not uncommon in the non .NET world. It is a way of maintaining multiple versions of the
same application and differentiating them.
 
Back
Top