one more on designing netcf custom controls

[Guest]

I just switched to VS2005 and I need to port a .NET controls lib to .NETCF

First here's my current understanding / state of research - pls correct me
if I am wrong:

Under VS03 a control with designer support had a single source file, used
NETCFDESIGNTIME to block out non designtime attributes and you had two
projects using the same set of source files but different build configs.
Attributes used for the designer built were System.ComponentModel.Category,
..Description (plus maybe some others I haven't found yet). With defining an
assembly attribute the designer was told what the control actually was he is
supposed to use while in design mode.

Now (VS05) has changed especially for .NETCF. Attributes are only maintained
in the class diagram and not returned into the source code but instead are
kept in an external attributes file my IDE names DesignTimeAttributes.xmta
(however I too found other names which work)

Questions: - how/where is that controled


(and design as it seems in general):

 

[Guest]

oops, sorry - somehow my keyboard fired a premature send, so here we go on
again, pls disregard the first post:

I just switched to VS2005 and I need to port a .NET controls lib to .NETCF

First here's my current understanding / state of research - pls correct me
if I am wrong:

Under VS03 a control with designer support had a single source file, used
NETCFDESIGNTIME to block out non designtime attributes and you had two
projects using the same set of source files but different build configs.
Attributes used for the designer built were System.ComponentModel.Category,
..Description (plus maybe some others I haven't found yet). With defining an
assembly attribute the designer was told what the control actually was he is
supposed to use while in design mode.

Now (VS05) has changed especially for .NETCF. Attributes are only maintained
in the class diagram and not returned into the source code but instead are
kept in an external attributes file my IDE names DesignTimeAttributes.xmta
(however I too found other names which work )

Questions:

- how/where is that controled (the file name, the general mode etc) Any
hints - I could not find much on Designer support topis for VS05 so far?

- is it still working to configure the sources similarly to the 'old'
practice so that when porting from .NET to .NETCF I can maintain a single set
of sources? I am asking to avoid pitfalls ahead while I am looking for a
solution which avoids having to maintain a '3rd' parallell project
configuration (.NET .NETCF and .NETDESIGNTIME)

- other than with VS03 05 when adding source files to a project really
produces a copy, so you loose the ability to work on a single tree with
different config sets. Am I missing something? Any suggestions welcome.

Thanks ahead

tb

 

[Tim Wilson]

how/where is that controled (the file name, the general

mode etc) Any hints - I could not find much on Designer
support topis for VS05 so far?

See the following two resources.
http://msdn.microsoft.com/library/d...ml/create_migrate_designer_controls_vs2k5.asp
http://www.mooseworkssoftware.com/VS2005 Control.htm

is it still working to configure the sources similarly to the
'old' practice so that when porting from .NET to .NETCF
I can maintain a single set of sources?

Design-time attributes need to be extracted and placed in an xmta file and
any supporting designer code needs to be isolated in an assembly built
against the full .NET framework and installed into the GAC. See the first
link, above, for more on this process.

other than with VS03 05 when adding source files to a project
really produces a copy, so you loose the ability to work on a
single tree with different config sets. Am I missing something?

Are you referring to the ability to link to a file? You can still do this in
VS 2005.

 

[Guest]

Tim, thanks - that was quick and exactly what I was looking for! Basically
this leaves me with the conclusion that use of a given set of designer
supporting sources backward compatible for use with VS2003 is not a very
viable option - no problem.

Still a question: configuring the ONE source such that it can be compiled
against .NETCF AND .NET. Because I would like (need) to use the attributes
when I am building for .NET - and they are now gone. (Reason is I have
additional .NET based but VS-external tools which also need to work with the
metadata. The same applies in both cases btw: running the tools with metadata
access (in .NET)
and building the same controls towards both .NET and .NETCF (which from a
coding point of view I guess is achieved once the CF code runs on .NET - so
basically it's probably the same problem I am trying to solve)

Besides as apparently under CF there are limitations and the code has to
resolve those. But in order to keep all in one common source set, is there
anything better then using #if LABELS?

And, for the same reason (once the single source control issue mentioned
before is resolved): I was not referring to linking btw. but in the past
(VS03) I had e.g. configurations where I had several projects, some for NET
and some NETCF referencing the same source-tree and when I actually dragged a
file from e.g. an explorer windo into a source folder of a VS project, (or
from one project to another) just a link was being established. So I could
have multiple links from different projects towards the same source/include
files. Somehow this seems gone or I haven't found it yet under VS2005? When I
drag a piece of source into a project's source folder, I always end up with a
copy of the file, not just a reference (regardless if I press any of the
usual keys Alt, Ctrl etc).

I hope this is not asking too much and the length of my message helps to at
least clarify the questions ;-)

cheers
Theo

 

[Guest]

One more I now may have understood: (Am I right:?)

As my NETCF controls are backward compatible, a NET based editor, even if it
runs outside the VS IDE, will be able to access the NETCF control's
attributes (and use those controls for serialization etc., provided the
controls support the methods for that themselves).

So there is no need to generate a separate assembly / binary for the
control, I only have to separate the build in general for those tools to be
..NET (obviously) and the controls to be CF (only). And if I needed extended
versions of the controls for the full framework, I could then extend the
NETCF classes with more functionality (e.g. suporting more events) and build
those for use in the full framework.

OK, I admit, coming from ASM and C and all this OO stuff is still somewhat
new and a bit confusing too

 

[Tim Wilson]

Basically this leaves me with the conclusion

that use of a given set of designer supporting sources
backward compatible for use with VS2003 is not a very
viable option - no problem.

It can be done. But the choice is yours as to whether or not you fork the
code or link the code. If you want an example of how to link the code
between VS .NET 2003 and VS 2005 for a smart device custom control then you
can download the source that accompanies the article at the first link that
I posted.

But in order to keep all in one common source set, is
there anything better then using #if LABELS?

Not that I'm aware of. And this can, of course, get pretty messy.

So I could have multiple links from different projects
towards the same source/include files. Somehow this
seems gone or I haven't found it yet under VS2005?

You can right-click the project in Solution Explorer and choose to add an
existing item. Once you've located the existing item in the dialog, select
the dropdown arrow on the "Add" button and choose "Add As Link".

 

[Tim Wilson]

If I'm properly understanding what you're saying, then yes that sounds
right. Keep in mind that assemblies that have been compiled against the
Compact Framework can be retargetable to the full .NET framework. See the
information at the link below for a little more on this topic.
http://www.danielmoth.com/Blog/2004/09/retargetable-256.html

 

[Guest]

Tim,
thanks, that was really helpful to provide insight!
Cheers & Happy Easter Holidays
Theo