All posts in Visual Studio

I’ve been working with VS 2008 for quite a while now and since the beginning I found irritating the fact that web.config files close when you save them.

I usually (or constantly ;-)) hit ctrl-s for every change I make without this necessarily meaning that I’m through changing the file. In VS 2008 this means that I have to re-open web.config every time I do that.

What’s more interesting is that no one else seems to complain about that. I searched the web to find a way to work around that but I simply can not find anything on that.

Is this a VS bug,… am I the only one that think that’s a problem?


Protected: .Net Framework 3.5 breaks ASP.NET 2.0 web sites!

Categories: ASP.NET, Visual Studio, Web
Enter your password to view comments.

This content is password protected. To view it please enter your password below:


As always this time of year I begun thinking on all the things I want to read, listen, view and code during my summer vacation free time, even though I never get the chance to do all the things I plan to ;-).

So I’ve already bought my PSP extra memory (2GB) and plan to fill it with podcasts, webcasts and videos so I can watch on my free time. Technologies and products that I’m especially interested this summer include : Silverlight, WPF, WCF, Visual Studio 2008, Astoria, Jasper, Linq, .Net 3.5, C# 3.0 etc.

I’ve already begun searching for those but I would be grateful if you could give me a hand by proposing stuff you think I should definitely have a look at.


In case you’ve didn’t notice Marin has posted a comment regarding my WPFSubsonic project and to be more precise a way I can read my application configuration file through my custom Visual Studio Tool. Now I just need to port it to my solution that supports the INotifyPropertyChanged interface and ObservableCollection class so that SubSonic Object can be bound to WPF controls.


Thanks Martin


Over the years I’ve seen and/or participated on quite a few interesting projects but VisualWebGui is probably the best work I’ve ever came across.


VisualWebGui is a project that tries to unify the development model of Web and Windows Forms development. So with VisualWebGui you can create a new project, design forms like you would have done for any windows forms application and run it on the web.


The Guy or guys behind this (I still haven’t found any references on who’s behind this) have made most of the window form controls not only emit html and render on a browser but also generate javascript ajax methods to handle the control events. They’ve even enabled debugging!


If you’re into web development but don’t want to get dirty with html you should probably check it out…


Kudos guys…


Some of you have been asking on my WPFSubsonic project status. Well I have to admit that things have been pretty hectic lately so I haven’t been able to complete it. I still haven’t found a way to pass configuration data on the custom tool but I have thought about it and I’m probably going to use XAML serializer/de-serializer in order to pass a configuration file to the custom tool.


For those of you that you simply can’t wait J, I’m posting a first built. In this build the DAL generation happens through a small executable file so that configuration can be performed through its App.config file.


I don’t know how many of you are interested or follow up on this effort. For those of you that do, I’m happy to say that the first release is very close.


The issue I still have to solve before publishing my code is the configuration one. Subsonic uses Web.Config to specify Database connection strings and the .Net 2.0 provider model to specify the Database drivers to be used. All these are configured in a custom configuration section that is read with a WebConfigurationSection descendant class at built time.


Since though custom build providers are not available at the Windows Forms platform I had to use another technique to emit the generated code in my programs. For this I decided to use Visual Studio Custom Tools following Dino Esposito’s article on MSDN Magazine. The problem with this implementation is that since your BaseCodeGeneratorWithSite class is registered as a COM object and created in Visual Studio’s scope, it has no longer access to types that could resolve the Custom App.Config Section (doesn’t know where to find the assemblies).


I’m thinking on putting the configuration section on the custom file that is passed on the BaseCodeGeneratorWithSite class as a parameter in the GenerateCode(string inputFileName, string inputFileContent) method. What do you think?


I usually nag about VSS but VSS is not always to blame when issues arise.  In the old VS2003 days when someone created a new Web Project, a  project (*.csproj or *.vbproj) file was automatically generated storing information about your website, its references and any used binary files. Thus when you needed to use source control for your web site project files binaries (dlls) didn’t have to be stored as well. Using the new feature of file system based web sites, all project files are now saved in a plain file system folder and there is no project file defining the web site references.  The referenced assemblies are just saved in a special folder called “bin” and the compiler knows that it has to look in that folder in order to get the required assemblies and built the site.


That’s all fine when you reference assemblies that don’t change (already built dlls). In this case, you just add them to source control as well. After they will be needed if someone else downloads the site from source control in order to build it. The problem arise when you reference another library project in your web site.  In this case the library assembly gets copied in your web site bin folder each time you built your solution and assuming that you’ve already added your website to source control, it will show the just copied assembly as a file that needs to be added to source control. If you go ahead and add it you’ll have to check it out each time you build your web site. If you choose to let VSS complain about it (it really gets on my nerves) and decide not to store binaries in your source control database (as you’ve probably learned at school) then the you’ll certainly be able to build without vss prompting you to check it out, but any other user that downloads your web site project from source control won’t be able to built it because of the missing assemblies.


I’m curious, how are you handling this issue?


After installing Vista RC1 the problems I had installing VSS were resolved so for a while I was quite happy working with VSS on Vista. Today though I’ve just stumbled across the following problem:


Assume that you have a network share containing a VSS database which you use to store your development team work, and that you’ve provided the right security privileges in that share so that everyone in your team can access and modify it.


Also lets assume that you’ re working on a project that requires running Visual Studio as administrator (elevated mode in UAC).


In this case you are not running Visual Studio with your account anymore and of course you can no longer access the network share containing the VSS Database, and thus cannot work with source control over your project.


What’s oxymoron is that if you want to work around this problem you must allow everybody access to the particular share[1], thus lessen the security on the share in order to tighten security on your local machine.


I believe that this is not something that was done intentionally but something that was not considered when implementing UAC and something that will be resolved in the final built but never the less it’s something that gets on my nerves.







[1] Of course you can always have 2 Visual Studios to work with, one running in UAC elevated mode to run your project and another in normal mode to edit it (this will run as your account thus having access to VSS Database share.


I’ve been playing around with WinFx… sorry .Net Framework 3.0 for quite some time now and faced a number of issues with those early releases with the most irritating one being the crashing of Visual Studio 2005 when, while debugging an application, an unhandled exception occurred. It’s comforting to see though that most of the things that annoyed my in those early releases have already been resolved by the VS Team in .Net Framework 3.0 beta 2.