[02/03] VS Bug??

Ok I had some time to make a sample project to demonstrate what I feel is a bug. Either that or I am doing something wrong here.

Attached is a simple windows form app project and class library project (both part of same solution)

the class library contains 1 class which extends to textbox class (just makes the font red, this is just to illustrate the fact that its a class inheriting from a control)

the windows forms app contains just 1 form, and references the class library project.

Open the project, and compile it in debug mode prior to viewing form1. This is because the class library DLL needs to be compiled before it can be used on the form.

After that if you view form1, it looks just like a simple little form. You can run the project, it should work just fine.

Close any open documents in the IDE (not the solution, just any .vb files that are open)

now, set the project to release mode, and select "rebuild solution" from the solution explorer. Once the compile is done, open Form1 in the designer, and see if the custom textbox control is still there, or if you get an error message stating VS couldn't find the type "VSBugLib.TextBoxEx" and the control is missing.

This has been a royal pain in the butt, and I have been trying to figure it out.

workarounds that fix this AFTER it happens, are changing back to debug mode, and compiling again, then closing VS and reopening the sln file. Deleting the obj folder works too, however that is not a solution to this issue.

Can others please confirm if this happens to them to, I tried it on 2 machines and got the same results. One machine is running VS.NET 2003 SP1 and one is running it without a SP

IDE Versions 7.1.6030 and 7.1.3088
Both have .NET framework 1.1 SP1

This only seems to affect the IDE, the actual compiled release mode exe functions fine.

Also I am not sure if all the steps above are nessesary to produce the issue, it may happen in less steps, however I steped through it and wrote it down as it happened.

Thanks,
Matt

I know this might sound a little crazy but it won't hurt to try it out.

I don't remember how 2003 works, but if it doesn't add a reference to the .DLL file generated from the "control library" project; Try adding one.

If a reference already exists try removing it and adding it manually

Because you know how Microsoft products work

I believe I know wht the issue is. What is displayed in the designer is the Debug version. The default behaviour for VS.NET 2003 is to use the 'bin' folder as the output target for both Debug and Release builds. When you compile a Release build the Debug build of your class library is deleted, so the IDE cannot find a Debug version of the control to display in the IDE. When you swtich back to Debug and rebuild the Release version is deleted and replaced with a Debug version and you're good to go again.

When I used VS.NET 2003 I always changed the output path for each configuration. I'd make them 'bin\Release' and 'bin\Debug', which is now the default behaviour in VS 2005. Now that each configuration outputs to a different folder your Debug version won't be wiped out by a Release build and the IDE shouldn't have any issues.

I had thought about that, but I think the problem lies with the obj folder and not the bin folder.

I tried setting different debug and release folders for each config, and I get the same results.

bump... did anyone actually try to and successfully reproduce the error?

I followed the steps and duplicated your error(s).

C:\Development\Testing\VSBugSLN\TestVSBug\Form1.vb(70): The variable 'TextBox1' is either undeclared or was never assigned.

Could not find type 'VSBugLib.TextBoxEX'. Please make sure that the assembly that contains this type is referenced. If this type is a part of your development project, make sure that the project has been successfully built.

Going to see about your proposed workaround...

Edit: all the designer generated code looks correct.

Running VS.NET 2003 SP1

Wondering if this is something I can get someone on the VB team at MS to look at and at least confirm what is going on, and perhaps propose a valid workaround. When I say valid, I mean one that doesn't require jumping through hoops.

I suppose I should also test to see if this exists in 2005 as well.

The exe in the bin folder runs fine and does contain the dll library dependancy.

The exe in the debug and release folders did not run and did not have the dll file dependancy.

I placed a copy of the dll in each of the debug and release folders next to the exe and they both ran.

Before recompiling I checked the VSBugEX reference in the solution explorer and the properties of the VSBugEX file was pointing to
C:\Development\Testing\VSBugSLN\VSBugLib\obj\Release\VSBugLib.dll
Which does not have the dll in that location. Seems the CopyLocal property does not work as its not copying it to the output location. The default location of the build output in the bin folder so maybe if you switch the path before recompiling to release mode it will work...

Yes, switching the output build path to the obj\release does place a copy of the dll in the same directory as the release exe but when closing and reopening of the designer it still errors the same. Only difference is that if you run the release exe manually it will work because the dll is already located in the app path. Closing and reopening of the solution works to solve the designer error. without the need to delete any obj folders

I do believe we should have some special access to the ms team. Havent used it yet but I do remember something about having special access of some kind.

We do get a couple of incident support calls but not that I would want to waste one on something that should be their issue and not a project / solution issue. ;)

I tried mentioning this problem in Microsoft Connect but it looks like Microsoft lost all interest in VS2003 after the release of the SP

ok so since 2005 has not only seperate debug and release folders, it also has debug and release folders in the obj directory as well.

So this raises 2 questions:

1) Is there a way to configure a 2003 project to spit debug and release output to different obj directories. I am going to check now, but I think maybe not??

2) Will this be something that is fixable, or MS will just recommend upgrading the project to 2005?

I would say that this sounds like a linking/refreshing issue even if the dll was in the correct folder nothing other then closing the solution and reopening it seems to relink it orrefresh it.


Upgrade, upgrade, upgrade :(

Quote:

---

Originally Posted by kleinma

Is there a way to configure a 2003 project to spit debug and release output to different obj directories. I am going to check now, but I think maybe not??

---

I'm sure there is, but I don't know how. Because in C#2003 project builds in 2 separate folders just like in VS2005

VB 2003 builds in the same folder "bin/" but you can specify separate build folders for debug and release but it still didnt make a difference as the bug was the same as when I tested the dll being in the release folder or not.

http://vbforums.com/attachment.php?attachmentid=51971

http://vbforums.com/attachment.php?attachmentid=51972

I think the issue is not in the BIN folder, but its in the obj folder.

I don't see a way to specify different obj folders for debug versus release.

Quote:

---

Originally Posted by RobDog888

We do get a couple of incident support calls but not that I would want to waste one on something that should be their issue and not a project / solution issue. ;)

---

There are also managed newsgroups for MVPs that you might try to see if you can get some sort of answer about it. Its in the Benefits Management section, same place where you can submit or use one of your two technical support incidents on the MVP site...

Quote:

---

Originally Posted by kleinma

I think the issue is not in the BIN folder, but its in the obj folder.

I don't see a way to specify different obj folders for debug versus release.

---

Look at my images again. ;) When you have it set on Debug type in your desired path. Then when you switch it to Release you can type in a different path. Switch back and fourth between the two modes to see the path switch back and fourth. :)

Quote:

---

Originally Posted by RobDog888

Look at my images again. ;) When you have it set on Debug type in your desired path. Then when you switch it to Release you can type in a different path. Switch back and fourth between the two modes to see the path switch back and fourth. :)

---

but those are different BIN folders, not OBJ folders.

The output path is where the final compiled exes and dlls go, but the intermediate directory (the obj folder) remains the same for both, even when you change the output path.

The only thing I didn't get from your picture, was why one is set to bin, and one is set to obj\release?

I typed it in there manually to change one from the other.

Quote:

---

Originally Posted by RobDog888

I do believe we should have some special access to the ms team. Havent used it yet but I do remember something about having special access of some kind.

We do get a couple of incident support calls but not that I would want to waste one on something that should be their issue and not a project / solution issue. ;)

---

By the way, if they acknowledge that it is a bug, MS will not charge you for the support call. I have a few free ones as part of a Universal Subscription, and have reported a few bugs in the past (all in VB6, but the model should be the same). Whenever the issue was clearly a bug, they told me repeatedly (MS can't be faulted for follow-up, they sometimes called back three times just to confirm that the problem was STILL resolved) that the incident didn't count against my free call total.

When I reported the ambiguous Breakpoint bug in VB6, they never clearly stated whether I would be charged for the incident, and I've always wondered.......,but not enough to follow up on it.

Good point shaggy. And also Matt, its closing in on the anniversary of our MVPs so we should use up the free incident calls before they expire?

the thing that really bothers me the most with this, is the fact that I feel like this is a pretty common thing to have. A referenced class library project in the same solution, and the class library has controls in it, that are using on forms in the main application.

How can this not be something that was noticed sooner?

That's true. In fact, when you describe it that way, this seems like one of the very purposes of DLLs: Custom crontrol exposure.

Where would you submit something like this or search for previous submissions?

I tried opening this with VS2005, and I got this straight the pic below straight away.

Was this what you're talking about Kleinma?

EDIT: When I tried changing the code for it to

VB Code:

Set Textbox1 = New System.Windows.Forms.TextBox

It says that it wouldn't change to it from the error message in the screenshot since the Option Strict stops it. If you have Option Strict on, try turning it off...

Did you rebuild the solution before opening any form/classes?

yeah you need to compile the source code. You get that error because I didn't zip the bin and obj folders.

Didn't really get a chance to try. I'll see later :)

Just an update.

I posted this issue in the private MVP newsgroups, although they don't seem to get a lot of traffic.

I emailed my MVP lead, and he is going to get back to me within a day or 2 and let me know where I can file this bug, since the connect site only seems to want 2005 bug reports.

Well......?

Well nothing....

I never got anywhere with this. I actually ended up moving the projects in question over to .NET 2.0 (which doesn't have the issue).

I have also found that if an issue exists in a .NET version that is no longer the "newest" one, but it is fixed in the most current version, they likely will not go back and fix it. I have even found bugs in .NET 2.0 that still exist in .NET 3.5 that they still are not going to fix until .NET 4.0