ResetDefaults function from VSIPHelper.Package class

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Bill Foust - 16 Feb 2005 15:31 GMT

I have a custom package that uses the VSIP Extras Package class as the base
class. We need to add Toolbox items so we have overriden the ResetDefaults
function to populate the toolbox whenever things get reset. This worked on
my developer machine, but now that I'm trying to do an install, it
apparently has stopped working. I added a messagebox in there, and it is
never getting shown. Ive done a "devenv /setup" as well as created the
"Toolbox" registry entry under my package to try to force a
re-registration. nothing seems to work. The only thing I can think of is
that we changed the package so that is is always loaded when vstudio starts
up instead of being loaded whenever it is needed. If a package is one of the
autoloading packages, does it not ever call ResetDefaults?
Any help would be appreciated.

Bill

Reply to this Message

Sergey M - 16 Feb 2005 17:09 GMT

Bill,

What's the UI context you use to auto-load your package? As you know,
after you run 'devenv /setup', VS last loaded solution option is reset.
Then when you start VS.NET your package may not load until "right"
context is activated or package's command is executed.

Signature

Sergey M
http://www.usysware.com/dpack/ - VS.NET package/add-ins
http://www.usysware.com/blog/

Reply to this Message

Bill Foust - 16 Feb 2005 19:25 GMT

I'm not sure I know the answer to that question. I set up the autoloading
with this attribute.

[MSVSIP.Helper.RegisterAutoLoad("{adfc4e63-0397-11d1-9f4e-00a0c911004f}")]

bill

> Bill,
>
> What's the UI context you use to auto-load your package? As you know,
> after you run 'devenv /setup', VS last loaded solution option is reset.
> Then when you start VS.NET your package may not load until "right"
> context is activated or package's command is executed.

Reply to this Message

Sergey M - 16 Feb 2005 20:06 GMT

> [MSVSIP.Helper.RegisterAutoLoad("{adfc4e63-0397-11d1-9f4e-00a0c911004f}")]

Yep, that's what I was asking about. I don't have VSIP SDK installed
here but what VSIP const does that UI context guid correspond to? The
reason I'm asking is that I don't have that guid in registry for my VS
installation here.

Signature

Sergey M
http://www.usysware.com/dpack/ - VS.NET package/add-ins
http://www.usysware.com/blog/

Reply to this Message

Sergey M - 16 Feb 2005 22:44 GMT

> I'm not sure I know the answer to that question. I set up the
> autoloading
> with this attribute.
>
> [MSVSIP.Helper.RegisterAutoLoad("{adfc4e63-0397-11d1-9f4e-00a0c911004f}")]

That appears to be a UICONTEXT_DesignMode guid. So, you're fine as far
as the guid goes. You're aware that your package won't be loaded until
design mode context is activated, right? Code text editor and designer
have their own context Ids. Thought I'd point that out.

Signature

Sergey Mishkovskiy
http://www.usysware.com/dpack/

Reply to this Message

Bill Foust - 17 Feb 2005 17:00 GMT

I've been at this a year and I still feel there is so much about VSIP I
don't know. LOL
What I really want is to have my package loaded up when MS VStudio is
launched.We have a custom project which calls into this package (through a
proffered service) when it is compiled and the only way I know to make sure
that the package is loaded when the coompile happens is to make the package
be loaded when vstudio is launched. I thought that this GUID was the right
one, but maybe not.

The original problem however may not even be related to this. the original
problem is that ResetDefaults is not getting called. I added a message box
to the package initialization and the ResetDefaults. when I launch Vstudio
on my virtual PC, I do see the message box for the intialization, but I do
not see the ResetDefaults message box. This is true even when I twidle the
Toolbox registry setting under the package GUID. It all works fine of my
developer PC (or course)

Thanks
Bill

> > I'm not sure I know the answer to that question. I set up the
> > autoloading
> > with this attribute.

[MSVSIP.Helper.RegisterAutoLoad("{adfc4e63-0397-11d1-9f4e-00a0c911004f}")]

> That appears to be a UICONTEXT_DesignMode guid. So, you're fine as far
> as the guid goes. You're aware that your package won't be loaded until
> design mode context is activated, right? Code text editor and designer
> have their own context Ids. Thought I'd point that out.

Reply to this Message

Sergey M - 17 Feb 2005 17:14 GMT

> I've been at this a year and I still feel there is so much about VSIP
> I
> don't know. LOL

Oh, I know exactly how you feel. I've started with general extensibility
and a year later decided to convert it to VSIP. I've had lots of "fun"
in the process.

> the original
> problem is that ResetDefaults is not getting called. I added a message
[quoted text clipped - 8 lines]
> my
> developer PC (or course)

Consider exporting your VS experimental registry key on your dev PC and
7.1 key on your VPC and diff the two files. You may be able to find some
registry package related discrepancies. Perhaps package post-build
registration adds some registry key where as your installation
application doesn't.

Signature

Sergey M
http://www.usysware.com/dpack/ - VS.NET package/add-ins
http://www.usysware.com/blog/

Reply to this Message

Bill Foust - 17 Feb 2005 23:44 GMT

Well upon further examination, the problem is in fact that the package is
not loading up at all on the virtual pc. I assume there is some dependency
that is keeping MS Vstudio from loading the package,but I have no idea how
to track that down. Is there something like DEPENDS for .NET? that was a
great tool.

Ive looked at the manifest in ILDASM and can tell that all of the assemblies
that I've made that it uses is installed into the same directory with it. I
know its possible for .NET to still not be able to load them for some
reason.

I tried making a testloader to test what can or cannot be loaded. Its a
console app that simply called Assembly.Load and passes in the arg. It
always fails, so there must be something wrong with it.

anyway, bottom line is that you were right and the package is not loading
up, but I still don't have a real good idea as to why.

Bill

> > I've been at this a year and I still feel there is so much about VSIP
> > I
[quoted text clipped - 22 lines]
> registration adds some registry key where as your installation
> application doesn't.

Reply to this Message

Sergey M - 18 Feb 2005 00:02 GMT

Hi Bill,

> Well upon further examination, the problem is in fact that the
> package is
[quoted text clipped - 5 lines]
> was a
> great tool.

Do you have VSIP interop assemblies installed on VPC? You can find an
.msi to install that under <..\VSIP 7.1\EnvSDK> folder.

One other thing to watch out is registry settings. As I've mentioned
before, I'd suggest you diff to PC (your w/s and VPC). I've often had
problems with package not loading due to some missing package registry
key/value.

Hope this helps.

Signature

Sergey Mishkovskiy
http://www.usysware.com/dpack/

Reply to this Message

"Ed Dore [MSFT]" - 17 Feb 2005 20:32 GMT

Hi Bill,

Don't do that! Seriously, if everyone attempted to have their package(s)
loaded on IDE startup, most people probably prefer Notepad over DevEnv.

:-)

If you register your proffered service correctly, the IDE will load the
package that implements the service, when the service is queried for. If
the package needs to be loaded in conjunction with your custom project
system. Then you should use push a context guid for your project, and use
this guid with that RegisterAutoLoad attribute. That way the package in
question will load when you've loaded a custom project.

If I recall correctly, this context guid for your project will be the one
you pass to IVsRegisterProjectTypes::RegisterProjectType, and returned from
your Hierarchy's project node via GetGuidProperty for VSHPROPID_CmdUIGuid.

Let me know if this doesn't make sense.

Sincerely,
Ed Dore [MSFT]

This post is 'AS IS' with no warranties, and confers no rights.

Reply to this Message

Bill Foust - 17 Feb 2005 23:49 GMT

HAHA. Well you will be glad to know that this package won't be generally
available. Its an internal tool only, so there will only be a half-dozen
guys in my company using it.

Still, I think I would like to do it your way, but I really only understood
about half of what you said. A blog or KB or something that breaks it down
into smaller steps would be useful.

Having said that, I'm still focused on getting this this to work at all in
my virtual PC. I'm getting closer, but the package won't load and I don't
have a real good idea as to why. Does it make a log somewhere? Unfortunately
something lke "mypackage or one of its dependancies failed to load" won't be
real helpful. if I would say "mypackage failed to load because the assembly
MyAssembly was not foung." that would help a lot.

Bill

> Hi Bill,
>
[quoted text clipped - 19 lines]
>
> This post is 'AS IS' with no warranties, and confers no rights.

Reply to this Message

"Ed Dore [MSFT]" - 18 Feb 2005 22:12 GMT

Hi Bill,

A package can fail to load for any number of reason, and unfortunately
there isn't any kind of logging mechanism (we are exposing a logging
service for Whidbey), which makes it pretty hard to figure out why a
package fails to load.

Couple of quick questions:

Did you install the VSIP SDK and the VSIP Extras addition on the target
machine?
Are you running DevEnv with the "/rootsuffix Exp" switch to test your
package?
Have you verified that the registry keys your package registers actually
appear in proper registry location (note, this will be determined by what
you pass with that /rootsuffix switch).
If you are not installing the VSIP SDK on the target machine, did you apply
a package license key (PLK) to your resource UI dll?
Finally, if you did install the VSIP SDK, can you build one of the sample
VSIP packages and get that to work?

Thanks,
Ed Dore [MSFT]

This post is 'AS IS' with no warranties, and confers no rights.

Reply to this Message

Rate this thread:

ResetDefaults function from VSIPHelper.Package class

Free Magazines