Managed Project Sample problems

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Don Caton - 10 Jan 2006 16:27 GMT

I've run into a number of problems with the managed package sample, and
there is virtually no documentation for this sample other than the class
reference, and significant parts of that are empty boilerplate pages.

I have successfully build the project, changed necessary class names and
guids, etc. and for the most part it works fairly well. However...

If you select multiple items in the add existing items dialog, an
exception is thrown on line 934 in HierarchyNode.cs (C:\Program
Files\Visual Studio 2005
SDK\2005.12\VisualStudioIntegration\Common\Source\CSharp\Project\HierarchyNode.cs).
A dialog box pops up with the very unhelpful message "Value does not
fall within the expected range". What value, what range???

Perhaps __VSADDITEMFLAGS.VSADDITEM_AllowMultiSelect on line 939 is the
problem. The docs indicate that this isn't supported. Why it is used
if it isn't supported? Surely it was tested though, so I have to think
I'm just doing something wrong, maybe I didn't implement a required
override or something in my inherited project class.

Second problem: dragging and dropping files from an explorer window to
the project tree does nothing. The cursor properly changes when
hovering over the property tree, but nothing at all happens when the
file(s) are dropped, not even an error message! Problem seems to be in
DragDropHelper.GetDroppedFiles(). On line 333 in DataObject.cs, the
call to QueryGetData() fails because it is only looking for the custom
clipboard types registered in the static ctor of DragDropHelper. Why
isn't it looking for dragged files?

The combination of these two bugs prevents you from adding multiple
files to a project, either via the add existing files dialog or via a
drag and drop operation. Surely this isn't intentional.

Third problem: add a .resx file to the project and then try to open it.
When VS opens the resource editor window, I get the following error
message: "Unable to cast object of type
'System.Collections.Generic.KeyValuePair`2[System.String,EnvDTE.Property]'
to type 'EnvDTE.Property'.". What on earth does this mean? Since
there's no source code for any of the managed wrapper assemblies, I
can't even look inside with Reflector to try and figure out what the
code is expecting.

Clearly, VS knows to use this particular editor as the default for resx
files, so I assume there is there some specific setup I need to do in my
inherited project class. But there's no documentation.

Also, why does ProjectNode.IsCodeFile() return false? Shouldn't this
method be abstract?

And finally, why is PropertyPageTypeConverterAttribute re-implemented in
Attributes.cs? It doesn't work, and the enums in StructuresEnums.cs do
not display properly in the options page property grid when this
attribute is used! Adding the proper
Microsoft.VisualStudio.Shell.PropertyPageTypeConcerterAttribute to the
enums causes them to display correctly.

Thanks.

--
Don

Reply to this Message

Steve Maillet (eMVP) - 10 Jan 2006 21:30 GMT

>there is virtually no documentation for this sample other than the class
>reference, and significant parts of that are empty boilerplate pages.

Unfortunately, That's generally true of most of the Managed Package
Framework (MPF). But it beats dealing with the C++ versions of things.
That's an appalling mess of cryptic macros layered on more cryptic macros.

Signature

Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

Reply to this Message

Don Caton - 10 Jan 2006 23:04 GMT

> >there is virtually no documentation for this sample other than the class
> >reference, and significant parts of that are empty boilerplate pages.
> Unfortunately, That's generally true of most of the Managed Package
> Framework (MPF). But it beats dealing with the C++ versions of things.
> That's an appalling mess of cryptic macros layered on more cryptic macros.

Yes, I know. I also spent quite a bit of time building a project based
on the MyC sample, and out of frustration I thought I would take a look
at the managed project sample to see if it was any simpler to
understand. I like a good challenge and I really would prefer to do
this in C++ anyhow, but I have work to get done and I can't spend the
next 6 months writing a project package.

Maybe I'm just frustrated, but the whole thing seems unnecessarily
complicated. If you need a wrapper around something to make it usable,
why not just make it usable to start with? I can't imagine having to
write all the code that's in either the managed or unmanaged samples, at
least not without decent, well organized information.

At least if the sample code was documented it might help, but there
isn't even as much as a readme file. Arrgh... I hope someone from MS
can at least answer my questions. At the moment I can't decide whether
to use the managed or unmanaged samples as a starting point...

--
Don

Reply to this Message

"Ed Dore [MSFT]" - 12 Jan 2006 02:21 GMT

Hi Don,

I just started looking into the multiple file selection issue using that
December CTP drop. I was able to reproduce this quite readily with the
Project sample. Will post back here as soon as I have an idea on how to
support this. Will try to hit your other questions as well.

Currently, implementing project systems isn't anywhere near as easy as we'd
like it to be. The Hier7Util stuff was based directly off of the same
native codebase we used to implement the VC, VB and C# project systems. The
MPF project codebase is still a work in progress. One of the reasons we
shipped it as sample code, was so that partners can change and fix things
to suite their needs.

My own take on this, is that the samples are only documented insofar as we
shipped the source. I do expect to see more in-depth documentation by way
of howto type topics going foward. But this is still a work in progress, so
attempting to document it in detail, is an attempt to hit a moving target
in some respects. Our doc folks have made a lot of improvements since the
VS2003 VSIP stuff. That's not to say there isn't a lot of room for
improvement, but I suspect that over time, we'll see the documentation
fleshed out a bit more. If you have specific suggestions, do send them
along to vsipfb@microsoft.com.

As for the managed .vs native approach, I would probably choose managed.
There's a lot more work currently going on in the managed project
scenarios, and with the Iron Python project sample, I suspect we'll see
additional improvements.

Using the HierUtil7 code is a pain, as it's not really compatible with the
code generated by the native package wizard code. Meaning, you basically
have to build/architect your native project off of one of the existing
samples. I'm not sure what the current plans are for improving or wrapping
that functionality into VSL, but until that happens, my recommendation is
to go managed.

Sincerely,
Ed Dore [MSFT]

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

Reply to this Message

Don Caton - 12 Jan 2006 14:10 GMT

Hi Ed:

> I just started looking into the multiple file selection issue using that
> December CTP drop. I was able to reproduce this quite readily with the
> Project sample. Will post back here as soon as I have an idea on how to
> support this. Will try to hit your other questions as well.
> Thanks for your reply and for looking into these issues. I found another one last night.

File, Save As raises the same cryptic "Value does not fall within
expected range" error. I've traced this down to line 2355 in
HierarchyNode.cs. The call to SaveDocData() apparently is failing. The
parameters appear to be valid, but at that point I hit a brick wall. I
spent several hours tracing through the asm code, and control appeared
to be in a routine that was setting up the Save As dialog when it
failed.

Now the thing is, this only seems to happen on source code files of my
project type. If I add a .resx file to the project, Save As on that
works fine.

I compared the code in HierarchyNode.SaveItem with the equivalent code
in Heir7 (CVsHierarchy::SaveItem, beginning at line 824 of hy_archy.cpp)
and both pieces of code seem to be doing the same thing. And there's
code in HierarchyNode.SaveItem to deal with Save As (see the comments at
line 2368) so this must have worked at one time.

> Currently, implementing project systems isn't anywhere near as easy as we'd
> like it to be. The Hier7Util stuff was based directly off of the same
> native codebase we used to implement the VC, VB and C# project systems. The
> MPF project codebase is still a work in progress. One of the reasons we
> shipped it as sample code, was so that partners can change and fix things
> to suite their needs.

I don't mind fixing stuff, but there's a point where you hit a brick
wall either from lack of documentation, or because you reach a point
where there's no source code or symbolic debug info. for the code you're
trying to debug.

> Using the HierUtil7 code is a pain, as it's not really compatible with the
> code generated by the native package wizard code. Meaning, you basically
> have to build/architect your native project off of one of the existing
> samples.

Yes, the whole thing is very confusing. There are multiple ways to
build a project system, various small samples that show fragments of how
to do something, but no simple coherent guidance on the recommended way
to build a complete project system from start to finish. And that's
what I'm doing. This is a commercial product and depends heavily on VS
integration.

We will be forking out the $10k to join the premier partner program as
soon as the contracts are drawn up by MS, and we will be distributing
the VS shell with our language. I'm sure Seattle is a nice place, but
given our tight development schedule I'd like to avoid a trip to one of
the VSIP workshops if possible. But our language package has to work
properly and be solid so these issues are real important to us. I
appreciate any help you can provide, and I'll try to narrow down any
problems I find as far as I can.

Thanks.

--
Don

Reply to this Message

"Ed Dore [MSFT]" - 13 Jan 2006 00:04 GMT

Hi Don,

Welcome aboard the VSIP Premier program. If you do get a chance to attend
one of the VSIP developer labs, I can highly recommend them. Seattle is a
nice in the summer, but I'm getting pretty weary of the rain of late. I try
to attend the quarterly devlabs along with our lead architects and
developers. The feedback we've received from those partners that attend has
been extremely positive to date. That being said, I realize tight schedules
can constrain such activities.

The problem with adding multiple existing files to the project is due to a
number of bugs in the implementation of ProjectNode.AddItemWithSpecfic (in
ProjectNode.cs).

In this function we made an incorrect assumption that the VSADDRESULT[]
result argument was allocated to the same size as the number of files to be
added to the project. This is not the case, and this argument only ever
holds one return value.

To fix the problem, you'll need to change that first conditional statement
to read something like the following:

if (files == null || result == null || files.Length == 0 ||
result.Length == 0)

Additionally, there are a number of places where this function refers to
result[index], these all need to be changed to result[0]. That should allow
you to add multiple files to the project successfully. I was able to verify
that we've already checked in a fix for this, so it will appear in the next
VS SDK drop.

The dragdrop problem is also known and we're working on getting that
squared away as well. I'll post back here as soon as I have more details on
that and the other items you mentioned in your earlier posts.

Sincerely,
Ed Dore [MSFT]

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

Reply to this Message

Don Caton - 13 Jan 2006 03:42 GMT

Ed:

> Welcome aboard the VSIP Premier program. If you do get a chance to attend
> one of the VSIP developer labs, I can highly recommend them. Seattle is a
> nice in the summer, but I'm getting pretty weary of the rain of late.

Thanks!

It's very hot here in the summer (Florida) so any chance to escape it
would be good, and I'm sure it would be a very worthwhile trip. Do you
know the date of the next lab? We have a developer's conference coming
up in March in London and I'm trying to get as much done as possible by
then, so I wouldn't be able to come out there until at least the 2nd
quarter of this year.

> To fix the problem, you'll need to...

Thanks, that indeed fixed the problem. It does seem odd that the result
parameter is an array; I would have also expected it to contain the same
number of elements as there are files being added.

However, there appears to be another bug. The ASADDITEMOPERATION
argument is VSADDITEMOP_OPENFILE, yet the code copies the added files to
the project directory anyhow. This should only happen on
VSADDITEMOP_CLONEFILE. I see where this is happening and I can fix it,
but this whole routine looks like it needs a rewrite.

Couple of other issues....

1) I don't see any documentation for the Code Definition Window. I have
enough work to do as it is so I'm not concerned about that right now,
but the menu command is always visible. In ShellCmdDef.ctc on line 154,
shouldn't guidVSStd2K:cmdidCodeDefView have the DYNAMICVISIBILITY flag
set?

I've added this command id to the VISIBILTY_SECTION of my .ctc file in
an attempt to hide it when my project is active but it has no effect,
presumably because the command doesn't have the DYNAMICVISIBIBILITY
flag. Is this intentional?

2) In IDEBuildLogger.cs, on lines 121 and 152, I had to add "-1" after
"errorEvent.LineNumber" because all the line numbers in the error task
window were off by one. Apparently, OutputTaskItemString() expects line
numbers to begin at 0, but my compiler (probably all compilers) use line
numbers starting at 1.

3) Why doesn't IVSOutputWindowPane::OutputTaskItemString() have a
parameter for the column number? There are "column" and "project"
columns in the error list window but there doesn't appear to be any way
to populate them. The C# project system displays column numbers, and
I'd like to as well.

Thanks again for your help.

--
Don

Reply to this Message

Don Caton - 27 Jan 2006 13:33 GMT

> The dragdrop problem is also known and we're working on getting that
> squared away as well. I'll post back here as soon as I have more details on
> that and the other items you mentioned in your earlier posts.

Ed:

Any word on any of these issues that I posted a couple of weeks ago?
Not being able to open the resx editor is probably the most pressing
problem at the moment. Not being able to use File Save As and the drag
and drop issue aren't as critical at the moment.

Thanks.

--
Don

Reply to this Message

Managed Project Sample problems

Free Magazines