VS2005 controls designer - file open

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

More questions on forms design....

I am generating a control from inside VS2005 and deploy it to the IDE
directory as I found referenced somewhere around here.

Now, once the designer has opened my DLL I am no longer able (as obviously
the designer is keeping the DLL file open) to go for any more design cycless,
unless I fully exit VS. Closing any (all) designer tabs won't help, and
sometimes VS seems even quicker than I and repoens before I can fire the
rebuilt.

Now: is there any trick how to get the designer to unload and close the file
so I can build - maybe as a prebuilt action?

CHeers and thanx ahead
tb
 
The following scenario works ok for me...

(1) In one instance of VS 2005, create a solution with a PPC 2003 (2.0)
control/class library project containing a smart device custom control.
(2) Compile the control.
(3) In another version of VS 2005, create a solution with a PPC 2003 (2.0)
application project containing a smart device application.
(4) Add the custom control assembly to the toolbox from within the
application project.
(5) Drag and drop the control from the toolbox onto the form, a reference to
the custom control assembly should be added to the application project.
(6) Go back to the instance of VS that is editing the custom control, make
changes and recompile.
(7) Go back to the instance of VS that is editing the application,
recompile.

Are you doing something different from this?
 
The only difference I can see is that I have both the control and the simple
testapp I am using to test the control in the same solution and thus in the
same running instance of VS.

The problem seems to be that the VS designer while I am testing the control
is keeping the control DLL open - immediately after a designer window is
opened - and without me having to drag the control on the form (It's there
already anyways from the last session). So I don't see how that's being
solved by having a second instance of VS running.

OK, just verified this with a 2nd VS but the problem remains - what you're
describing as step 6 fails: here's the error:
Error 1 Unable to copy file "obj\Debug\myControls.dll" to
"C:\Programme\Microsoft Visual Studio 8\Common7\IDE\myControls.dll". The
process cannot access the file 'C:\Programme\Microsoft Visual Studio
8\Common7\IDE\myControls.dll' because it is being used by another
process. myControls

C:\Programme\Microsoft Visual Studio 8\Common7\IDE\ is the build target
directory from which I added the control to the #1 VS toolbox as a result of
the (now) #2 VS built.

??
 
Further checking shows that apparently the #2 VS is the owner that has the
file open. So only after closing this I can delete the control DLL.

??
Theo
 
The only difference I can see is that I have both the control and the
simple
testapp I am using to test the control in the same solution and thus in the
same running instance of VS.
Click to expand...

If that's the case then one of the nicest things about control development
in VS 2005 is that if a control is detected in the solution it will
automatically (only within the solution, however) be available in the
toolbox. This is really nice for testing purposes. Try removing the toolbox
entry that you manually added, remove the control reference from the
application project, and then look through the toolbox for the custom
control that's in the solution (it should be at the top of the toolbox). Use
this to drag and drop controls on the form and see if that makes a
difference.
 
Tim,

that's exactly what I already had in the first place, so maybe I Don't
understand what you're suggesting?

I had both the NETCF control and a testing app inside the same solution,
with just a single VS2005 instance running. And, yes, VS autodetected the new
control (great!) and offered it for drag and drop in the toolbox of the NETCF
test app.

But then (regarless btw. if I use a single or 2 VS instances) - the DLL
file is kept open and thus can not be rebuilt unless I a) close all designers
(so they don't reopen at next project load) and b) close all VS instances.

There must be a way to shut down the designers inside the IDE such that the
control DLL gets released -> that's what I need and (IMHO) what should be
automated during a control-redeploy or rebuilt session in the first place.
(It is in fact a nice feature that VS automatically places the new control
into the toolbox - but somehow the integration should be possible in a
repeated cycle).

So in case this is not an issue with anything I could configure but missed
so far, maybe some macro or prebuilt code in general could force the designer
(of the presently running VS instance of cause) to close the open DLL (or
close the entire designer)?

Thanks again for your thoughts!

Theo
 
(It is in fact a nice feature that VS automatically places
the new control into the toolbox - but somehow the
integration should be possible in a repeated cycle).
Click to expand...

The only time that I have had a problem is when doing something elaborate -
ex. a smart device custom control project, a smart device test application
project, and a full .NET framework project that contained the custom
designer logic for the control which was automatically being installed into
the GAC on successful build, all in the same solution. Even then it wasn't
referring to an assembly that couldn't be overwritten, it was just choking
in the designer when it went to refresh the form. In a basic scenario, what
you're attempting to do should definitely work. Try the following steps,
with a new clean solution, and see if this works...

(1) Create a new Smart Device, Pocket PC 2003, Control Library [2.0]
project.
(2) Compile the new Control Library project.
(3) Add a new Smart Device, Pocket PC 2003, Device Application [2.0] project
to the solution.
(4) From within the forms designer with the new Device Application project
form open, drag an instance of the custom control associated with the
Control Library project onto the form.
(5) Go back to the Control Library project and make a change, such as
changing the BackColor to green.
(6) Rebuild the Control Library project - the rebuild should be successful.
(7) Switch back to the forms designer and you should see the change that you
made with the custom control reflected on the form.
 
Seems we're getting closer. My Solution file actually contains an unmanaged C
Lib, an unmanaged C exe for testing that lib, the NETCF custom control plus
a NETCF Device APP for testing the control

Will try as you suggested and we'll see - I still don't understand why the
unmanaged apps schould interfere with the designer or cause it to keep files
open....

cheers
Theo
 
Ok. Let me know how it goes.

--
Tim Wilson
..NET Compact Framework MVP

tb2000 said:
Seems we're getting closer. My Solution file actually contains an unmanaged C
Lib, an unmanaged C exe for testing that lib, the NETCF custom control plus
a NETCF Device APP for testing the control

Will try as you suggested and we'll see - I still don't understand why the
unmanaged apps schould interfere with the designer or cause it to keep files
open....

cheers
Theo

The only time that I have had a problem is when doing something elaborate -
ex. a smart device custom control project, a smart device test application
project, and a full .NET framework project that contained the custom
designer logic for the control which was automatically being installed into
the GAC on successful build, all in the same solution. Even then it wasn't
referring to an assembly that couldn't be overwritten, it was just choking
in the designer when it went to refresh the form. In a basic scenario, what
you're attempting to do should definitely work. Try the following steps,
with a new clean solution, and see if this works...

(1) Create a new Smart Device, Pocket PC 2003, Control Library [2.0]
project.
(2) Compile the new Control Library project.
(3) Add a new Smart Device, Pocket PC 2003, Device Application [2.0] project
to the solution.
(4) From within the forms designer with the new Device Application project
form open, drag an instance of the custom control associated with the
Control Library project onto the form.
(5) Go back to the Control Library project and make a change, such as
changing the BackColor to green.
(6) Rebuild the Control Library project - the rebuild should be successful.
(7) Switch back to the forms designer and you should see the change that you
made with the custom control reflected on the form.
Click to expand...
Click to expand...
 
Hi,
just one question.
what are you referencing in your test application?
did you set a reference to the library, located in the control library's target folder, or
you set a reference to the control library project?
it does make a sense, because of in case of setting a reference to the
target binary executable , VS will load it and won't allow changing it
if you set a reference to the project, VS will unload the referenced library, recompile it and then load it again.
More questions on forms design....

I am generating a control from inside VS2005 and deploy it to the IDE
directory as I found referenced somewhere around here.

Now, once the designer has opened my DLL I am no longer able (as obviously
the designer is keeping the DLL file open) to go for any more design cycless,
unless I fully exit VS. Closing any (all) designer tabs won't help, and
sometimes VS seems even quicker than I and repoens before I can fire the
rebuilt.

Now: is there any trick how to get the designer to unload and close the file
so I can build - maybe as a prebuilt action?

CHeers and thanx ahead
tb
 
Tim, Martin, thanks again, I think I found it and the last post by Martin too
explains it.

I initially deployed the control DLL to the IDE directory as target dir for
the built and referenced the DLL there - apparently this keeps the file open
and: Bang!

Tim, after following your suggestions I am now able to recompile both the
control and the app and it even looks in the designer of the app that once
the control is recompiled the app designer reloads the control. Great - first
step taken!

Now occasionally I get a red x and a thrown exception in the designer when
it apparently has some issues with my code ?? I am not sure but a rebuilt of
the control and things look ok then....

One observation though still strange to me:

My control initially had the attributes in "old style" #if
NETCFDESIGNTIME..., #endif, causing the class diagram to not pick up the
attributes??? Only after adding the attribute in the class diagram I then get
the xmta file but now it seems I have a double set of the attributes, one in
the code and one in the xmta file?

??

(We're getting there... ;-) )
 
My control initially had the attributes in "old style"
#if NETCFDESIGNTIME..., #endif, causing the
class diagram to not pick up the attributes???
Only after adding the attribute in the class diagram I
then get the xmta file but now it seems I have a double
set of the attributes, one in the code and one in the
xmta file?
Click to expand...

The attributes need to be transfered from the #if blocks to the xmta file.
This process is manual labor in that it's not automated - you'll need to
move them all yourself. Unless you need to support a design-time experience
in VS .NET 2003 then you can remove the #if blocks that contain the
attributes. All you need is the xmta file in VS 2005.
 
VS 2005 knows nothing about design time attributes, so it does not handle them
if you don't want to use the same sources to compile both 2003 and 2005 versions of
the controls, move all the code of NETCFDESIGNTIME blocks away
and add description of these porperties and events into xmta files, otherwise
let them alone, it does not hurt VS 2005 compiler in case if you did not put
NETCFDESIGNTIME as additional compilation directive


Tim, Martin, thanks again, I think I found it and the last post by Martin too
explains it.

I initially deployed the control DLL to the IDE directory as target dir for
the built and referenced the DLL there - apparently this keeps the file open
and: Bang!

Tim, after following your suggestions I am now able to recompile both the
control and the app and it even looks in the designer of the app that once
the control is recompiled the app designer reloads the control. Great - first
step taken!

Now occasionally I get a red x and a thrown exception in the designer when
it apparently has some issues with my code ?? I am not sure but a rebuilt of
the control and things look ok then....

One observation though still strange to me:

My control initially had the attributes in "old style" #if
NETCFDESIGNTIME..., #endif, causing the class diagram to not pick up the
attributes??? Only after adding the attribute in the class diagram I then get
the xmta file but now it seems I have a double set of the attributes, one in
the code and one in the xmta file?

??

(We're getting there... ;-) )
 
Back
Top