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

Own TypeConverter - Only works after restart of Visual Studio

P: n/a
Hello,
the problem seems to be complex and is in all developments of web-controls
which uses own TypeConverter.
For this I have here a simple demo-program of the problem:

The Control-code: A class MyString which is a class which is similar to a
string
[TypeConverter(typeof(MyStringTypeConverter))]
public class MyString
{
string str;
public MyString(string str) { this.str = str; }

public override string ToString() { return str; }

public string Str
{
get{ return str; }
set { str = value;}
}
}

the typeconverter used:

class MyStringTypeConverter : TypeConverter
{
public override bool CanConvertFrom(ITypeDescriptorContext context,
Type sourceType)
{
if (sourceType == typeof(string))
{ return true;}
return base.CanConvertFrom(context, sourceType);
}
public override bool CanConvertTo(ITypeDescriptorContext context,
Type destinationType)
{
if (destinationType == typeof(string))
{return true;}

else if (destinationType == typeof(InstanceDescriptor))
{
return true;
}

return base.CanConvertTo(context, destinationType);
}
public override object ConvertFrom(ITypeDescriptorContext context,
System.Globalization.CultureInfo culture, object value)
{
if (value is string)
{
return new MyString((string)value);
}
return base.ConvertFrom(context, culture, value);
}
public override object ConvertTo(ITypeDescriptorContext context,
System.Globalization.CultureInfo culture, object value, Type
destinationType)
{
if (destinationType == typeof(string))
{
MyString cls = (MyString)value;
return cls.ToString();
}
else if (destinationType == typeof(InstanceDescriptor))
{
ConstructorInfo ci = typeof(MyString).GetConstructor(new
Type[] { typeof(string) });
MyString cls = (MyString)value;
return new InstanceDescriptor(ci, new object[] {
cls.ToString() });
}
return base.ConvertTo(context, culture, value, destinationType);
}
}

the control-class:
[DefaultProperty("Text")]
[ToolboxData("<{0}:TestCtrl02 runat=server></{0}:TestCtrl02>")]
public class TestCtrl02 : Control
{
[Bindable(true), Category("Appearance"),Localizable(true)]
public MyString Text
{
get{
MyString s = (MyString)ViewState["Text"];
return ((s == null) ? new MyString("") : s); }

set
{ ViewState["Text"] = value; }
}

protected override void Render(HtmlTextWriter writer)
............

}

using in a page:
.............
<cc1:TestCtrl02 ID="testCtrl" runat="server" Text="my text" >
</cc1:TestCtrl02>
...................
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxx

ok seems many code, but is the shortest possible to see the problem.

The problem:
The program is compiled, we now
start Visual Studio.
Now if we go in the html-view of the page we see:
<cc1:TestCtrl02 ID="testCtrl" runat="server" Text="my text" >
</cc1:TestCtrl02>
Now we change to the design view:
the property Text now has in property view under property Text 'my text'.
If we change the text in the property and go to the html-view all is fine.
So, all works fine.
NOW: We make a RE-build of the project. Nothing more.
Now we open the page-file in html-view. All is fine.
Now we change to the design view: Error Creating Control 'my text' cannot be
set on property Text.
If we now close Visual Studio and start it again, All works fine.
If we now delete the text, and make a RE-build, so we have
<cc1:TestCtrl02 ID="testCtrl" runat="server" >
</cc1:TestCtrl02>
we can go to design view without problems.
If we now enter in the Text-property : my text we get an error:
Property value is not valid: MyString cannot be converted to type MyString.
We now close Visual Studio and start it again and do the same.
Now it works fine.

So I know such problem allway are there when I use TypeConverter I think the
following:
After a rebuild the own type converters are not seen from the visual studio
environment.

So what maybe the reason, what can be a solution.
Developing web-controls with typconverters and to start Visual Studio after
each rebuild is impossible.

sorry it's much text, but the problem is fundamental and very important for
me.
Thank you for any help.
Rolf Welskes


Sep 28 '06 #1
Share this Question
Share on Google+
11 Replies


P: n/a
Hi Rolf,

I was able to reproduce the issue you've experiencing. I'm currently
consulting with our product team to see if this is a known issue and
whether or not there would be a workaround. Thank you for your patience and
understanding.

I do find that this issue only exists when the TypeConverter and customer
control are in another class library in the solution; if they're in
website's App_Code directory (use "__code" as the assembly name when
registering customer control), it works correctly after rebuiding the
solution.

I will get back to you as soon as possible, thank you for your feedback.

Sincerely,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications. If you are using Outlook Express, please make sure you clear the
check box "Tools/Options/Read: Get 300 headers at a time" to see your reply
promptly.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Sep 29 '06 #2

P: n/a
Hello,
thank you for your response.
I do not work with Visual Web Designer, but with Web Projects.
This means, I do not have a App_Code directory.
So in any case I have the error, clearly the Control and the TypeConvert are
in an extra control-library.
It would be very important to have a work a round.
Thank you again.
Rolf Welskes

"Walter Wang [MSFT]" <wa****@online.microsoft.comschrieb im Newsbeitrag
news:pm****************@TK2MSFTNGXA01.phx.gbl...
Hi Rolf,

I was able to reproduce the issue you've experiencing. I'm currently
consulting with our product team to see if this is a known issue and
whether or not there would be a workaround. Thank you for your patience
and
understanding.

I do find that this issue only exists when the TypeConverter and customer
control are in another class library in the solution; if they're in
website's App_Code directory (use "__code" as the assembly name when
registering customer control), it works correctly after rebuiding the
solution.

I will get back to you as soon as possible, thank you for your feedback.

Sincerely,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications. If you are using Outlook Express, please make sure you clear the
check box "Tools/Options/Read: Get 300 headers at a time" to see your
reply
promptly.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no
rights.

Sep 29 '06 #3

P: n/a
Hi Rolf,

Sorry for reply late.

Which Visual Studio version are you using?

I've confirmed this is an issue of Visual Studio 2005; I have reported this
problem to our product team. You are also encouraged to submit your
feedback at
http://connect.microsoft.com/Main/co...ContentID=2220. You
can use this thread as a reference.

I'm sorry that using a separate class library in the same solution, there's
no knowing workaround now. The only workaround is to use the TypeConverter
and custom server control inside the same web project using App_Code and
"__code" as the assembly name when registering the control.

If you are using Web Application Project add-on of VS2005, you can also use
the App_Code feature. Just right-click on your Web Project and add "Add
ASP.NET folder/App_Code".

If you are using Visual Studio 2003, I've verified that this issue doesn't
exist in Visual Studio 2003 SP1.

Thank you very much for your feedback on this issue. Please let me know if
there's anything I can further help.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Oct 2 '06 #4

P: n/a
Hello,
thank you for your reply.

the workaround is not fine to develop large projects.
I hope this will be solved in a service pack.

Remark: There are also other situation when the changes in code in a
customer control is not recognized by VS2005 and the only way is to restart
VS.
In this time I have to restart VS 100 times a day or more. Not fine.

But ok.
Hope it will be solved in the next service pack.

Thank you.
Rolf Welskes


"Walter Wang [MSFT]" <wa****@online.microsoft.comschrieb im Newsbeitrag
news:u%****************@TK2MSFTNGXA01.phx.gbl...
Hi Rolf,

Sorry for reply late.

Which Visual Studio version are you using?

I've confirmed this is an issue of Visual Studio 2005; I have reported
this
problem to our product team. You are also encouraged to submit your
feedback at
http://connect.microsoft.com/Main/co...ContentID=2220. You
can use this thread as a reference.

I'm sorry that using a separate class library in the same solution,
there's
no knowing workaround now. The only workaround is to use the TypeConverter
and custom server control inside the same web project using App_Code and
"__code" as the assembly name when registering the control.

If you are using Web Application Project add-on of VS2005, you can also
use
the App_Code feature. Just right-click on your Web Project and add "Add
ASP.NET folder/App_Code".

If you are using Visual Studio 2003, I've verified that this issue doesn't
exist in Visual Studio 2003 SP1.

Thank you very much for your feedback on this issue. Please let me know if
there's anything I can further help.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no
rights.

Oct 5 '06 #5

P: n/a
Hi Rolf,

I fully understand your concerns. I've already filed a bug for it. Thank
you very much for your feedback!

Have a nice day!

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
Oct 6 '06 #6

P: n/a
Hello,
you write:

If you are using Web Application Project add-on of VS2005, you can also use
the App_Code feature. Just right-click on your Web Project and add "Add
ASP.NET folder/App_Code".

This does not work, if you have a Web Application Project there is under the
menu point "Add ASP.Net Foller" no App_code.
Some other, but no App_Code item.

I have tried to add the folder by hand means I have added a folder App_Code.

But if I use this, there is now own dll / assembly for the code of this
folder.

Furthermore the problem to restart VS aftter each changes is not away.

Any ideeas what to do?

Thank You
Rolf Welskes


Oct 6 '06 #7

P: n/a
Hi Rolf,

Thanks for the update.

I checked again using Web Application Project, it already compiles the web
project into a single assembly (the name is set by project properties). So
there's no need of App_Code -- any folder will do. Apparently I missed this
point in last reply, sorry for the confusion.

So far based on my research and feebacks from consulting, only the assembly
"__code", which is generated from normal VS2005 Web Site's App_Code, are
correctly recogonized after rebuilding the whole web site.

Also, from the warnings generated by rebuilding the web project using Web
Application Project mode:

The type 'mynamespace.TestCtrl02' in
'c:\projects\web_wap_TypeConverter\App_Code\Class1 .cs' conflicts with the
imported type 'mynamespace.TestCtrl02' in
'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Tem porary ASP.NET
Files\web_wap_typeconverter\a47d81e7\_shadow\ee1b9 bbd\1963687437\29813569\we
b_wap_TypeConverter.DLL'. Using the one in
'c:\projects\web_wap_TypeConverter\App_Code\Class1 .cs'.
c:\projects\web_wap_TypeConverter\Default.aspx.des igner.cs

It seems the VS2005 IDE failed to delete the previous built assembly when
rebuilding. This should be the root cause of this issue. I will add this
updated information to the bug I opened for this issue. Thank you very much
for your feedback!

So far, the only working workaround would be have to use default Web Site
mode in VS2005 and use App_Code.

I understand this may not be feasible for your project. If it's critical
for your business, I suggest you contact PSS for further assistance.

For PSS support or a local on site, you can also try contacting the global
support center through the following link:

http://support.microsoft.com/gp/assistsupport

They will provide you the detailed info on how to contact the local
developer support center.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Oct 9 '06 #8

P: n/a
Hello,
thank you for your work.
Hoping that it will be solved in the next service pack.

Thank you again.
Rolf Welskes
"Walter Wang [MSFT]" <wa****@online.microsoft.comschrieb im Newsbeitrag
news:Rd**************@TK2MSFTNGXA01.phx.gbl...
Hi Rolf,

Thanks for the update.

I checked again using Web Application Project, it already compiles the web
project into a single assembly (the name is set by project properties). So
there's no need of App_Code -- any folder will do. Apparently I missed
this
point in last reply, sorry for the confusion.

So far based on my research and feebacks from consulting, only the
assembly
"__code", which is generated from normal VS2005 Web Site's App_Code, are
correctly recogonized after rebuilding the whole web site.

Also, from the warnings generated by rebuilding the web project using Web
Application Project mode:

The type 'mynamespace.TestCtrl02' in
'c:\projects\web_wap_TypeConverter\App_Code\Class1 .cs' conflicts with the
imported type 'mynamespace.TestCtrl02' in
'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Tem porary ASP.NET
Files\web_wap_typeconverter\a47d81e7\_shadow\ee1b9 bbd\1963687437\29813569\we
b_wap_TypeConverter.DLL'. Using the one in
'c:\projects\web_wap_TypeConverter\App_Code\Class1 .cs'.
c:\projects\web_wap_TypeConverter\Default.aspx.des igner.cs

It seems the VS2005 IDE failed to delete the previous built assembly when
rebuilding. This should be the root cause of this issue. I will add this
updated information to the bug I opened for this issue. Thank you very
much
for your feedback!

So far, the only working workaround would be have to use default Web Site
mode in VS2005 and use App_Code.

I understand this may not be feasible for your project. If it's critical
for your business, I suggest you contact PSS for further assistance.

For PSS support or a local on site, you can also try contacting the global
support center through the following link:

http://support.microsoft.com/gp/assistsupport

They will provide you the detailed info on how to contact the local
developer support center.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no
rights.

Oct 11 '06 #9

P: n/a
Hi Rolf,

After I reported this issue to product team, I'm still working closely with
product team on it. After done more researching and consulting, we've found
a workaround for this issue.

The type converters go straight to the CLR's cache of type information and
do not go through the type resolution service implemented by the project
systems. This means that the CLR will return the type from the assembly it
had previously loaded prior to the rebuild - and the conversion will fail
since the type on the design surface is being loaded from the newly built
assembly. I verified that you can work around this by ensuring the version
number of the class library project gets auto-incremented on each build.
You do this by the following:
1) Bring up properties on the class library project
2) Select the "Application" tab and click the "Assembly Information..."
button.
3) In version the field set the last entry to a "*" - so it should say: 1 0
0 *

Now whenever the classlibrary is built, the revision number (the last digit
of the version) will be auto-incremented. This forces the CLR to invalidate
the entry it has cached and load the new one.

Please let me if this works for you. Thank you for your patience and
understanding in this post.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
Oct 25 '06 #10

P: n/a
Hallo,
this is fine, it works fine.
Thank you for your work.
I am very happy because allways restart is much work.
Thank you again.
Rolf Welskes
"Walter Wang [MSFT]" <wa****@online.microsoft.comschrieb im Newsbeitrag
news:4q****************@TK2MSFTNGXA01.phx.gbl...
Hi Rolf,

After I reported this issue to product team, I'm still working closely
with
product team on it. After done more researching and consulting, we've
found
a workaround for this issue.

The type converters go straight to the CLR's cache of type information and
do not go through the type resolution service implemented by the project
systems. This means that the CLR will return the type from the assembly it
had previously loaded prior to the rebuild - and the conversion will fail
since the type on the design surface is being loaded from the newly built
assembly. I verified that you can work around this by ensuring the version
number of the class library project gets auto-incremented on each build.
You do this by the following:
1) Bring up properties on the class library project
2) Select the "Application" tab and click the "Assembly Information..."
button.
3) In version the field set the last entry to a "*" - so it should say: 1
0
0 *

Now whenever the classlibrary is built, the revision number (the last
digit
of the version) will be auto-incremented. This forces the CLR to
invalidate
the entry it has cached and load the new one.

Please let me if this works for you. Thank you for your patience and
understanding in this post.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no
rights.


Oct 25 '06 #11

P: n/a
Hi Walter,

After googling for one whole day I was so glad to find this workaround
and also relieved to find out that the VS team was onto it.

I have applied the workaround you mentioned, and the error

'Object of type 'MyType'' cannot be converted to type 'MyType''

does not appear any longer. Result!

However, I am not using a TypeConverter and I simply have a
List<MyTypeas a property of my control, and now I have the following
error:

'Object of type 'System.Collections.Generic.List`1 cannot be converted
to type 'System.Collections.Generic.List`1''

Would you by any chance know a workaround for this? Is there any way I
can avoid implementing a TypeConverter?

Thanks in advance,
Ben.

Walter Wang [MSFT] wrote:
Hi Rolf,

After I reported this issue to product team, I'm still working closely with
product team on it. After done more researching and consulting, we've found
a workaround for this issue.

The type converters go straight to the CLR's cache of type information and
do not go through the type resolution service implemented by the project
systems. This means that the CLR will return the type from the assembly it
had previously loaded prior to the rebuild - and the conversion will fail
since the type on the design surface is being loaded from the newly built
assembly. I verified that you can work around this by ensuring the version
number of the class library project gets auto-incremented on each build.
You do this by the following:
1) Bring up properties on the class library project
2) Select the "Application" tab and click the "Assembly Information..."
button.
3) In version the field set the last entry to a "*" - so it should say: 1 0
0 *

Now whenever the classlibrary is built, the revision number (the last digit
of the version) will be auto-incremented. This forces the CLR to invalidate
the entry it has cached and load the new one.

Please let me if this works for you. Thank you for your patience and
understanding in this post.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
Nov 3 '06 #12

This discussion thread is closed

Replies have been disabled for this discussion.