In the Line of Fire -- Ramblings of the incoherent mind

Had to revert back to exec task of nant and use the Devenv.exe to build the solution as I had some weird assembly referencing problems.

While building the solution it was looking for the references one level above the directory containing the assemblies

couldn't figure out what the problem was :( since I was short on time,had no option but to use the exec task and directly build the project solution, it solved my problem but I still need to figure out a solution to my earlier problem of wrong references

using Devenv solved the problem but not sure if that's one of the accepted approach and whether I should use an *external exe to build the solution than find a solution to the problem arisen out of using the solution task provide by nant

Am writing an article on howto implement Cruisenet and Nant in continous integration which will include the steps to follow to setup cruisenet and nant on your build server and how to implement the integration.

Hope this article will solve the problems faced by first timers and save a lot of their time from doing R n D :)

* By external I mean a .exe out of nant tasks , nant might be internally using Devenv.exe to compile the projects who knows.

Had to revert back to exec task of nant and use the Devenv.exe to build the solution as I had some weird assembly referencing problems.

While building the solution it was looking for the references one level above the directory containing the assemblies

couldn't figure out what the problem was :( since I was short on time,had no option but to use the exec task and directly build the project solution, it solved my problem but I still need to figure out a solution to my earlier problem of wrong references

using Devenv solved the problem but not sure if that's one of the accepted approach and whether I should use an *external exe to build the solution than find a solution to the problem arisen out of using the solution task provide by nant

Am writing an article on howto implement Cruisenet and Nant in continous integration which will include the steps to follow to setup cruisenet and nant on your build server and how to implement the integration.

Hope this article will solve the problems faced by first timers and save a lot of their time from doing R n D :)

* By external I mean a .exe out of nant tasks , nant might be internally using Devenv.exe to compile the projects who knows.

Starting solution build. BUILD FAILED Error checking whether 'http://localhost/ProjectDirectory/projectname.csproj'

is an enterprise template project. The remote server returned an error:

(403) Forbidden. Total time: 0.3 seconds.

that's the error that I got when the nant build script tried to build the Web Project I tried out diff stuff but didn't succeed for quite some time maybe was missing something important,dint know what to do then something struck me, when we define a virtual directory we have diff options.

And one of the important ones there is "script source access" especially in our case as we are trying to access the files in the virtual directory and build them using nant scripts

The reason for this happening is that IIS has a strict access setting for the virtual directories that it hosts and it doesn't allow any scripts to access the files in the virtual directory's physical folder and hence the message The remote server returned an error: (403) Forbidden



one of the way to solve this problem is by checking the option of script source access in the virtual directories properties







Here is the place where you can check the option to allow script access to your code files for getting rid of the Nant forbidden error

Starting solution build. BUILD FAILED Error checking whether 'http://localhost/ProjectDirectory/projectname.csproj'

is an enterprise template project. The remote server returned an error:

(403) Forbidden. Total time: 0.3 seconds.

that's the error that I got when the nant build script tried to build the Web Project I tried out diff stuff but didn't succeed for quite some time maybe was missing something important,dint know what to do then something struck me, when we define a virtual directory we have diff options.

And one of the important ones there is "script source access" especially in our case as we are trying to access the files in the virtual directory and build them using nant scripts

The reason for this happening is that IIS has a strict access setting for the virtual directories that it hosts and it doesn't allow any scripts to access the files in the virtual directory's physical folder and hence the message The remote server returned an error: (403) Forbidden



one of the way to solve this problem is by checking the option of script source access in the virtual directories properties



Here is the place where you can check the option to allow script access to your code files for getting rid of the Nant forbidden error

Building the invidiual sub projects first and then referencing the compiled assemly (in build folder ) in the main project turned out to be a bad idea. After completing the build thought of testing (fortunately!! ) it for build success and a build failure.



For the failure I removed a much needed reference (one of the sub projects) from the main project and then checked in the project file and was expecting a build fail email from ccnet (CruiseNet) but was baffled to see a success mail instead.



A little bit of thinking on it got me to the much obvious reasons (was stupid of me not to have foreseen that) the process I was following was of building the sub-projects and pushing the compiled sub project assembly in the build folder and then the project would reference the sub project assembly from the build folder.

The problem was even though I had removed the reference from the main project file, my compiling of the sub project would automatically push the assembly in the build folder

and since we have to hard code the references it would find it and give a successful build even though it was a failure.



moral :- Use a solution task and build the solution instead of individual projects to automatically detect the references in the project.

Building the invidiual sub projects first and then referencing the compiled assemly (in build folder ) in the main project turned out to be a bad idea. After completing the build thought of testing (fortunately!! ) it for build success and a build failure.

For the failure I removed a much needed reference (one of the sub projects) from the main project and then checked in the project file and was expecting a build fail email from ccnet (CruiseNet) but was baffled to see a success mail instead.

A little bit of thinking on it got me to the much obvious reasons (was stupid of me not to have foreseen that) the process I was following was of building the sub-projects and pushing the compiled sub project assembly in the build folder and then the project would reference the sub project assembly from the build folder.

The problem was even though I had removed the reference from the main project file, my compiling of the sub project would automatically push the assembly in the build folder

and since we have to hard code the references it would find it and give a successful build even though it was a failure.

moral :- Use a solution task and build the solution instead of individual projects to automatically detect the references in the project.

Just came across a stale news on net posted in oct sometime anyways here it is :-



Microsoft has posted guidance that protects against a reported vulnerability in all versions of ASP.NET that could allow a Web site visitor to view secured content by using specially crafted requests to a Web server. For more information http://www.microsoft.com/security/incident/aspnet.mspx