By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,608 Members | 3,801 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,608 IT Pros & Developers. It's quick & easy.

Deployment problem with framework 1.1 SP1

P: n/a
I am reposting in this group after getting no response for a week in the
deployment group.

I have a setup project that uses custom actions. The project installs and
runs fine on machines that have the .NET framework 1.1, but fails on machines
that have .NET framework 1.1 SP1. The specific error message is:

"Unable to get installer types in the <assembly path> assembly. One or more
of the types in the assembly unable to load"

Any ideas?

Thanks,
Pat

--
Pat
Nov 21 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
I would bet that it is a versioning problem. I have seen that message
outside the context of MSI installations and it was in the following
scenario: you make a .NET application that supports assemblies plug-ins, all
managed code. The plugin needs a reference to the application in order run,
so it is compiled referencing a specific version of the host application. If
later you recompile the application and give it a new version, when it tries
to load the assembly plugins via managed Load, LoadFrom, etc. functions, you
get that error.

I warn you right now that custom actions on .NET assemblies and MSI
installations are a source of problems. Now, combine the previous with the
following article that I wrote:

BUG: Visual Studio .NET Setup Projects Execute Custom Action of Previous
Version when Upgrading
http://support.microsoft.com/?id=555184

So, if you are doing tests reinstalling and you are changing versions
between tests, you get a mess.

The following thread gives some insight about how the Windows installer
works internally:

http://groups.google.com/groups?hl=e...3DN%26tab%3Dwg

--

Carlos J. Quintero (Visual Developer - .NET MVP)

The MZ-Tools all-in-one add-in, now for .NET: http://www.mztools.com
"pmcguire" <pm******@discussions.microsoft.com> escribió en el mensaje
news:86**********************************@microsof t.com...
I am reposting in this group after getting no response for a week in the
deployment group.

I have a setup project that uses custom actions. The project installs and
runs fine on machines that have the .NET framework 1.1, but fails on machines that have .NET framework 1.1 SP1. The specific error message is:

"Unable to get installer types in the <assembly path> assembly. One or more of the types in the assembly unable to load"

Any ideas?

Thanks,
Pat

--
Pat

Nov 21 '05 #2

P: n/a
Hi Carlos,

Thanks for the reply. I've read the threads you provided, and, although I'm
not ENTIRELY clear on everything going on in them, I'm pretty sure that my
situation is a little different. In my case, no previous versions exist.
Let me go through the steps:

1) Create an application and deployment package with custom actions on a
development machine. It does not appear to matter whether the development
machine (machine A) has SP1 or not.

2) Use the Bootstrap configurator to make a boostrap install package for
some theoretical, non-MSDE endowed production machine (machine C).

3) Install successfully on a machine with .NET Framework 1.1 (not SP1)
(machine B)

4) Give package to client for use

5) Listen to client complain that install (on machine C) fails

6) Learn that client has SP1 installed

7) Uninstall application from machine B, install SP1 on machine B, and try
but fail to install application on machine B.

So, it could be a versioning problem, I suppose, but it would have to be a
versioning problem that is sort of created by a failure on the part of the
PACKAGER to include an updated version, rather than the CONSUMER to recognize
it. Also, I'm not sure that I mentioned this before, but removing the custom
actions makes the symptons disappear.

Thanks,

Pat

Nov 21 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.