Problem:

Your projects in Visual Studio 2005 are behaving strangely, sometimes not building with funny errors, and tend to marked as modified in your source control

When trying to isolate the problem:

you diff your *proj file against a previous version and find this entry:

<Service Include="{B4F97281-0DBD-4835-9ED8-7DFB966E87FF}" />

Why is it happening?

You probably have installed VS 2005 SDK, with the DSL tools.

It has a bug in the Text Templating service.

Should have been fixed in VS SDK RTM 4.0, but it hadn't (apparently, as it happened on my machine after installing RTM 4.0)

I saw a promise that the on Orcas SDK it's fixed. I guess that mean that in VS 2005 SDK it won't get fixed.

How to solve (dirty - but working):

using your favorite registry editor, locate
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Packages\{a9696de6-e209-414d-bbec-a0506fb0e924} and
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0Exp\Packages\{a9696de6-e209-414d-bbec-a0506fb0e924}
remove (or rename) them, and the Text Templating service won't start, and your *proj files would stay intact.

However:

If you do need the Text Templating service, then I can't help ya.

Read also at:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=954064&SiteID=1

Another nice news from Scott Guthrie:

a small excerpt:

Today I'm excited to announce that we'll be providing this with the .NET 3.5 and VS 2008 release later this year.

I'm using VS2005 (with SP1, like duhh) and have had R# 3.0.1

Now, I'm not a fan of the default font and color scheme, as I like better the slicker mono-fonts, like Consolas. I am also becoming a Black-Background type, not for the WouldSaveTheRainForests==true reason (in LCD the light is static no matter what color it shows) but for the  implements IDLikeToKeepMyEyeSightForALongTime reason.

So, started with importing a color scheme from some internet-found-place, don't remember where, and then tried to change those Resharper coloring options (like, a variable name that is being used an odd amount of times, by internal classes, however not in an explicit-interface implemented method, that returns a struct), just to find out the the Fonts-And-Colors menu miss those lovely Resharper entries).

Okay, so what should I do? Export the settings, edit the xml, and re-import.  Not much fun there.

Hmm. Googled it (I may use the term, as I actually use Google as a search engine), and found a post on jetbrains support site, with the same problem.
no solution though.

However - this is how I solved it eventually:

1. Export the current settings to a file

2. Reset all settings

3. Re-install R# (hey - now it's 3.0.2 !!)

4. Import back my settings.

Here's a strange error message.

I was trying to build a project in VS2005, and got this instead of a successful build:

The "Exec" task needs a command to execute.

After pooling out a few hairs, I remembers that I recently have edited the pre-build actions for this project.

Looking this up, I found that I left a spare newline at the end of the pre-build script. So VS2005 sent msbuild an order to run an empty command.

Now I wonder, had the VS2005 guys have ever heard of StringSplitOptions.RemoveEmptyEntries?

They could've easily ignore empty lines, or better yet, issue a warning for that kinda stuff.

I've just got the announcement from the Ruby.NET team at QUT, about the new beta release, numbered 0.7.

The two major things in there:

1. the compiler now creates pdb files, which means that it can be debugged with the interactive debuggers,

2. Visual Studio 2005 integration, including Ruby projects.

Can't wait to check this out.

I'd like to see if I can do some integration into the AspView project, to enable a RubyOnMonoRail thing. I guess it'd have to wait for the BCL integration, promised to be released around the end of this year, but it is quite interesting as it is right now.

ActiveWriter is a VS2005 plugin, that adds a new item type for your projects. This item is actually a visual designer for ActiveRecord classes. Quite neat, and hopefully will increase the penetration of Castle's ActiveRecord to the "If there's no VS wizard, I do not use it" kinda guys.

You can read about it and download it from http://altinoren.com/activewriter/

The SP1 of Visual Studio 2005 was out, and it was (almost) great.

Why almost? If you have tried to install it, then you must know. It takes a LOT of time to run. And it uses a LOT of resources. If you do not believe me, take a look at what Ayende has been writing while installing it.

Luckily, Jon Gallowai has blogged about a patch to shorten the setup time.

Take a look, if you care for you cpu time.

What we have:

1. Default Helpers are now declared in the AspViewBase. It means that you can use <%=FormHelper.LabelFor(...) %> without the need to declare the helper at the begining of the view.

2. the compiler was refactored to allow for better testing, and for implementation of further view languages. vurrently I've started with VB.NET but it is not working yet, since I have no time to make sure the VB syntax is correct. The tests of the compiler are missing due to some stupidity on my side, of not commiting the TestCase ...

I've wanted to let svn access but I have some trouble with that. I've started a sourceforge project but I cannot upload the repo to the site. I did all they've asked on the site but the import process reporting failure no matter what I do. I guess that the best way will be if the Castle team would allow AspView into it's codebase, maybe on the Contrib repo to begin with ...

So meanwhile you can download the current bits from here.

Keep me posted,

Ken.

So I'm releasing AspView.

You can download the source from here.

It was written against the Castle 1.1 from the trunk, build no. 152.

Please note that in order to run the TestCases you'd have to make sure that the latest Castle.MonoRail.TestSupport is in the GAC.

The documentation is poor since I have a little time now. I am working on a website for my employer (that utilizes AspView and AR) and until the first beta release I won't have time to do anything but major bugfixes. This project isn't open sourced so I won't be able to share it's sources, however since this will be a public site, it would serve as a Proof Of Concept to the MonoRail and AspView.

The views MUST have the following structure:
    a. Page header - Must be present for intellisense to work:

   1:  <%@ Page Language="C#" Inherits="Castle.MonoRail.Views.AspView.ViewAtDesignTime" %>

    b. Directives - Not mandatory:

   1:  <%@ Import Namespace="System.Text" %>
   2:  <%@ Import Namespace="System.Drawing" %>

    c. Properties decleration - Currently it's mandatory. If you have no properties you mast have an empty block:

   1:  <%
   2:      string[] strings;
   3:      DateTime today;
   4:      int index;
   5:  %>

or just

   1:  <%
   2:  %>

    d. View body

In a layout view you place the inner view using the ViewContents property, like this:

   1:  blah
   2:  blah
   3:  <%=ViewContents%>
   4:  blah
   5:  blah

So what is AspView?

It is a Visual Studio 2005 friendly ViewEngine implementation.

The scripting is done using VisualStudio languages (c# and VB.NET). The views are precompiled, (or can be compiled on-demand, but anyway not interpreted).

The project was inspired by the Brail ViewEngine, but since it doesn't use Boo it is more Management-Friendly, since they need not worry about getting out of the "safe" microsoft world.

I tend to like Boo as a language very much, and I like Brail a lot, too (since it allows for less code in the view thanks to the Boo magic) but I lack the tight Visual Studio integration (opening .boo files in #Develop messes up my desktop), and the intellisense is quite important, at least for the developers I worl with.

So I will post in the next few days about it, and I'll make it available to be downloaded (source and binary) as soon as I'll test it a little more. I hope to have a public svn repository soon.

A little demo view:

   1:  <%@ Page Language="C#" Inherits="Castle.MonoRail.Views.AspView.ViewAtDesignTime" %>
   2:  <%
   3:      string[] strings;
   4:  %>
   5:   
   6:   
   7:  hello from index<br />
   8:  This are the strings:<br />
   9:  <%  foreach (string s in strings) { %>
  10:        <%=s %><br />
  11:  <%  } %>
  12:          
  13:  <br />
  14:  End of normal view
  15:  <br />
  16:  <% OutputSubView("Home/SubViewSample"); %>

Scott Guthrie has recently posted this. He is pointing out to a few dozens of posts about ASP.NET 2.0.

The stuff there ranges from UI tweaks, security, performance, VS2005 tips and more.

A "must be in the favorites or even as a desktop shortcut preferably with keyboard shortcut too" for everyone who deals with ASP.NET developing.

Well, Here's my first hopfully useful post in my blog.

The problem:

pdb files of projects and assemblies being referenced by a web application, somtimes become "source controlled" when using VS 2005 and VSS. This is leading to the pdbs and even dlls to become readonly, and therefore the break of a succesful post-build events, such as copying newly compiled dlls to the web application's Bin directory, hence unexpected behavior of the application.

The "Why the heck this is happening":

Using VS 2005 to develop ASP.NET 2.0 applications is somewhat different than in the good old VS 2003.

The main difference is caused by the missing project file.

As opposed to VS 2003, which compiled the cs (and vb) files of a web project using csc.exe (and vbc.exe), as with regular (not web) projects, things are different with VS 2005 web projects.

In order to allow on the fly compile of source files (codebehinds and App_Code files), and on the other hand, to allow a precompilation of the whole project (including aspx, ascx and other "non code" files), the framework has provided us with a special compiler, named aspnet_compiler.exe

allowing a full "automated" compiled outside of any IDE, requires disrelying on an IDE specific file, such as the csproj/vbproj files, therefore, everything in (and under) the application's directory considered to be a part of the project.

In VS 2003 the compiler knew about referenced dlls and projects from the csproj/vbproj file. Now referenced dlls are known throuh a .refresh file in the Bin directory, that points to the location of the dll, and referenced project files are written to a special section in the web.config.

Controlling the source manually using VSS interface is possible, yet you have to manually remember not to check in items from the Bin directory, except the .refresh files.

The VSS integretion in VS 2005 is trying to outsmart the problem. it assumes that if a .refrsh file exists in the Bin directory, then the file it references is not to be source controlled. For example: if the Bin directory contains a file names MyAssembly.dll.refresh, then if it also contains a file names MyAssembly.dll (and it will, after a succesfull build), it won't treat it as source controlled.

It also understands that if a file is there, due to a build action, it is also marked so it won't be source controlled.

But, if you build you solution in Debug configuration, now you have pdb files in the Bin directory. let's say that you do a Release Build, that does not create and copy pdb files. now the existing pdb files in the Bin directory are not marked, and the VSS integration will sense that there are new files in the Bin, that have no .refresh file, and was not created during the last Build event, so it will mark them as Check In Pending files !!!

The "Gosh it's Ugly solution":

You need to:
1. Rebuild the solution in Debug configuration
2. Close and Reopen the project.

If you've already accidently Checked In the pdb files, you need to:
1. Manually delete them from the VSS.
2. Manually set their readonly attribute to false.
3. Rebuild the solution in Debug configuration
4. Close and Reopen the project.

The place where i've found this solution: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=106422&SiteID=1

So until next time, keep on with the good coding thing you've been doing while you've start reading this post.

Ken