Hosting a Windows Control Library control in an ASP.NET 2.0 page, the WCL does not resize correctly, if you change the size of the IE Window. The problem does not occur using .NET Framework 1.1 The problem is a regression in Visual Studio 2005 which prevents the .Net ActiveX implementation from asserting managed code privilege when calling IOleClientSite::OnPosRectChange. Since that call requires managed code execution privileges, it fails and the control cannot resize itself. The workaround is to set the size of the control from the HTML rather than resizing it internally. For example, the onresize in the body tag in the following script does this: <html> <body onresize=”obj1.Width=document.body.clientWidth;”> <div style=”width:100%;height:100%;background-color:blue”> <OBJECT id=”obj1″ height=”90%” width=”90%” classid=”MyResizeControl.dll#MyResizeControl.UserControl1″ VIEWASTEXT /> </div> <br> This is a long string for me to test the other space </body> </html> Capitalization of the properties is important: capital “W” (Width) will correctly change the Width property of the internal .Net control; lowercase “w” (width) will change the property of the HTML object rather than the .Net object, and this will not work if the .Net object is 1.1. Cheers
-
-
Orcas Beta 1 released
I’m really not a marketing guy and don’t like that much the kind of shiny advertisements which makes everything looking like the best bargain ever, but I think this time it work making an exception to the rule š So, here is a bit of advertising: Visual Studio code name āOrcasā enables developers and development teams to rapidly create connected, secure and compelling applications on the latest platforms, including Windows Vista, Longhorn, the 2007 Office System and the Web The expanded and improved offerings in Visual Studio code name āOrcasā for software development teams, including tools for database professionals and greater collaboration between development organizations and designers Visual Studio code name āOrcasā delivers improvements to Visual Studio Team System that help software development organizations communicate and collaborate more effectively, providing greater predictability and reliability of their software development processes The .NET Framework 3.5, based on proven technology, adds new features in several major technology areas including: Deep integration of Language Integrated Query (LINQ) and data awareness throughout the runtime, compiler, and class libraries. This new feature will let code written in LINQ-enabled languages to filter, enumerate, and create projections of several types of collections using the same syntax Support for…
-
If Visual Studio takes ages to load…
… it might be that you opened a project/solution from a network share which is no longer available, or that is slow to refresh etc… I had this problem myself with Visual Studio .NET 2003 (not Visual Studio 2005 so far, so I’m not sure if this is also affected or not), and took a while to figure out what the problem was. Procmon and some patience to go through the log pointed me to an interesting registry key: HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\ProjectMRUList (the same key exists for VS 2005, but it’s under *VisualStudio\8.0\ProjectMRUList). This key contains the path of the last 20 solutions I opened/created; what’s interesting is that by default Visual Studio does not show all the recent solutions opened (in File menu or in the Start Page) but just the last 6 (I usually change this value to 10), but despite that it reads all the values and (I guess) verify if the solution is still available, thus the delay… To solve my problem I simply deleted the values pointing to a solution from a network share et voilĆ , Visual Studio was loading at the usual (reasonable) speed. Cheers
-
Unable to attach to process (on localhost)
Another interesting one I got a few days ago: after installing the SP1 for Visual Studio 2003, the customer was unable to debug his web application (on localhost) neither pressing F5 nor attaching to the target w3wp.exe process. As you can imagine, removing SP1 the problem disappeared. Moreover they hadĀ multiple machines running the same OS and software that worked fine, only one particular machineĀ was affected by this problem; more interestingly, other developers were able to remotely debug their application hosted on the affected server, so only debugging on localhost was not working (WinForm debugging was also working fine). Of course the account used to login on the server was a local administrator. The target platform we were running on was Windows Server 2003 R2 x64Ā on AMD Operton 280 (dual core, 2.4GHz) with 4GB RAM; IIS is configured to run in 32 bit mode (w3svc/AppPools/Enable32bitAppOnWin64 = TRUE), and of course Visual Studio .NET 2003 with Service Pack 1. To start troubleshooting this I did a quick research in our internal docs and it turner out that his is a known issue due to loopback check; basically the reason is because the underlying DEBUG request is getting a 401 response, causing the…
-
Visual Studio 2005 hotfixes made public for download
After readingĀ this post a while ago regarding the availability Policy for some hotfixes (e.g., not all hotfixes are public for download, and you have to call Microsoft Support to obtain the one you need), I had an internal discussion with my team on this topic. Basically those are some of the reasons (at least the one I know about) for this controversial choice: As stated in every KB article, those fixes have not gone through the same accurate testing as public fixes or Service Packs, so it’s possible that with a particular configuration the fix a customer request is not the right approach for him We keep track of the hotfixes we send to customers, and if a bug orĀ problem is later discovered in that particular fix, thanks for those records we know who has installed it and we are able to contact those customers to send them an updated version of the patch, or in any case inform them of the newly discovered problem and help them to avoid it More often than you can imagine, we receive clearly wrong hotfix requests: for instance, a particular exception in Framework 1.0 has been fixed and the KB article is still…
-
Sweet sorrow… remote debugging (and more)
Continuing from my previous post on common causes for memory leaks, remote debugging is another ASP.NET feature that has the potentiality to either delight (uhm… am I exaggerating here…? š) a web developer or drive him completely crazy š I remember 8-9 years ago, when I was a young technology passionate learning the basics of web development (HTML, CSS, ASP etc…), on my desk I just had a couple of programming books for beginners, my dial-up modem to download some online manuals and my copy of Office 97 for students. My editors at that time were FrontPage 97 and Notepad… so all I could do to debug my web pages were to use lots of Response.Write() to inspect variable values, and lot of brain work to try to understand where things were going wrong… With ASP.NET and Visual Studio .NET in these days developers still have to do lot of brain work, but for sure the tools now help a lot with debugging web applications… but what happens if the debugger has tantrums? š² Here is a list of the common debugger problems I saw so far in my experience with Microsoft Support; this is not at all a comprehensive…