Posts Tagged ‘Visual Studio’Visual Studio 2010 web publishing issue with the .browser filesFriday, May 14th, 2010We moved a VS 2008 web site project to VS 2010, and when we did a publish using the “Publish Web Site”, somehow all the customised Adapter classes that we implemented within the .browser files didn’t get executed. After a very thorough investigation, especially after we looked into the App_Browsers.dll assembly through a reflection tool, we found out that the publishing process altered the controltype attribute in the .browser files from this: System.Web.UI.WebControls.Menu, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a to this: System.Web.UI.WebControls.Menu, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a It seems that App_Browser.dll file generator of VS 2010 is making a bad assumption even though the target framework is set to .Net 3.5. Because the web application is set to run on 2.0 framework, those control type is not matched. Fortunately, we’ve figured a work around which is by deleting the App_Browser.dll and the related .compiled file out of the bin directory after publishing, and copy the uncompiled .browser files back into the App_Browsers directory.
Forms, Controls & the Forms DesignerMonday, April 14th, 2008I was just working on a Windows app that contains lots and lots of User Controls all of which inherit from a base User Control. When I opened the controls they displayed blank in the designer. After some digging I realised that two vital pieces were missing:
It seems the Forms Designer creates an instance of the control by calling the parameterless constructor (which seems obvious when you think about it I suppose). The giveaway on the InitializeComponent() call was the comment just above the call injected by default which reads “Required for Windows Form Designer support“. Anyways – hopefully this will save somebody some time.
VS.NET2003, Windows Vista & Remote DebuggingThursday, March 22nd, 2007If you’re like me you will have a development machine that’s got a bit of power behind it. You might also be a bit keen on new technology. You may have even gone ahead and installed Windows Vista thinking – she’ll be right. If you’re still like me at this point you’ll be thinking “bugger”. Visual Studio.NET 2003 is not supported on Vista = but it does work for the most part. The big issue is web development. What has worked for me, and may well work for you, is installing Windows XP on Virtual PC 2007 (free). I put my web sites on the XP VPC and I can still run the IDE on Vista. While this is a little clunky everything seems to work pretty well. Then one day… bang! The debugger refused to attach. Checking the event logs I found a very unhelpful Event ID 10023: “The application-specific access security descriptor for the COM Server application C:\Program Files\Common Files\Microsoft Shared\VS7Debug\mdm.exe is invalid. It contains Access Control Entries with permissions that are invalid. The requested action was therefore not performed. The application set this security permission programmatically; to modify this security permission contact the application vendor.” I have no idea what happened from one minute to the next but it was properly busted. I tried a million things including every known remote debugging setup check. I even reinstalled VS.NET 2003 & VS2005. The thing that eventually did the trick was:
I suspect there was another issue, and in trying to solve it I had added domain accounts to the DCOM config of Machine Debug Manager in “Access Permissions”. Further testing has revealed that this is what has killed it. If you are having this problem now you know why
|
Archives
Tag Cloud |
For some reason simply removing the offending accounts doesn’t help you have to perform the steps above.