Working with WebDeployment in MS Project files

by Shawn 25. January 2012 12:21

Great article: http://stackoverflow.com/questions/2959964/vs2010-web-deploy-how-to-remove-absolute-paths-and-automate-setacl

The displayed path is determined by the property _MSDeployDirPath_FullPath.

This property is setted by this chain of properties:

  • <_MSDeployDirPath_FullPath>@(_MSDeployDirPath->'%(FullPath)')</_MSDeployDirPath_FullPath>
  • <_MSDeployDirPath Include="$(_PackageTempDir)" />
  • <_PackageTempDir>$(PackageTempRootDir)\PackageTmp</_PackageTempDir>
  • <PackageTempRootDir>$(IntermediateOutputPath)Package</PackageTempRootDir>
_MSDeployDirPath_FullPath <-- @(_MSDeployDirPath->'%(FullPath)') <-- _PackageTempDir <-- $(PackageTempRootDir)\PackageTmp
AS you can see, you can't have a relative path, because _MSDeployDirPath_FullPath is the fullpath of _MSDeployDirPath.

But you can simplify the displayed path by overriding the property _PackageTempDir with the path you want to be displayed to your customer. (This path will be used as a temporary directory for the package generation)

You could override the property :

  • In command line :

    msbuild.exe projectfile.csproj /t:Package /p:_PackageTempDir=C:\Package
  • Or directly in the project file :

    <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
    <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
    
    
    <!-- Must be after Microsoft.WebApplication.targets import -->
    <PropertyGroup>
      <_PackageTempDir>C:\Package</_PackageTempDir>
    </PropertyGroup>

 

Tags: ,

Development

Looking for a way to list a row count for every table in a database? Look no further...

by Shawn 6. January 2012 08:34
SELECT OBJECT_NAME(OBJECT_ID) TableName, st.row_count
FROM sys.dm_db_partition_stats st
WHERE index_id < 2
ORDER BY st.row_count DESC
GO

Tags: ,

Development

Tool for working with .NET config file transforms

by Shawn 22. November 2011 20:19

Tags: , , ,

Development

Multiple app.config files (just like web.config files)

by Shawn 22. November 2011 20:17

Tags: , , ,

Development

Prevent ASP.NET web.config inheritance, and inheritInChildApplications attribute

by Shawn 17. November 2011 10:41
If you have ever had the scenario where you have a main ASP.NET web application and then need to create one or more sub virtual folders that contain completely independant applications (different authentication, error pages, etc), then you have probably run up against the need to prevent the normal web.config inheritianace.  Do do this is pretty simple, just setup the PARENT web.config like this
 
<!-- Root web.config file -->
<?xml version="1.0"?>
<configuration>

  <location path="." inheritInChildApplications="false"> 

    <system.web>

      <compilation debug="false" />

      <!-- other configuration attributes -->

    </system.web> 
  </location>
</configuration>
The one catch when doing this is that you'll probably notice Visual Studio compain about the "inheritInChildApplications" attribute.  Turns out this is because the Schema XSD files for web.config that shipped with VS2005/2008/2010 left out support for this attribute (Note: this doesn't prevent your app from work, it just means VS IDE will complain).
To fix this, open up the following files located in %ProgramFiles%\Microsoft Visual Studio XX\Xml\Schemas (XX is 8.0, 9.0, or 10.0 depending on your version)
  • DotNetConfig.xsd
  • DotnetConfig20.xsd
  • DotnetConfig30.xsd
  • DotnetConfig35.xsd
For each of the files -- Find the <xs:element name="location"> tag and change it to look like this
<xs:element name="location">
  <xs:complexType>
    <xs:choice>
      <xs:any namespace="##any" processContents="lax" />
    </xs:choice>
    <xs:attribute name="path" type="xs:string" use="optional" />
    <xs:attribute name="allowOverride" type="small_boolean_Type" use="optional" />
    <xs:attribute name="inheritInChildApplications" type="xs:boolean" use="optional" />
  </xs:complexType>
</xs:element>
Basically what you are doing is adding this one line to that complex type declaration
<xs:attribute name="inheritInChildApplications" type="xs:boolean" use="optional" />
 
And thatsit -- you're good to go.

Tags: , ,

Development

ASP.NET HttpModule Event Life cycle

by Shawn 2. November 2011 07:28

MSDN Article: http://msdn.microsoft.com/en-us/library/ms178473(v=VS.80).aspx

 

In my recent quest to integrate support for SiteMinder into the ASP.NET Membership process I found myself looking into the details of ASP.NET Http Modules.  Once of the areas that I spent time on was understanding the exact order of events in the life cycle of a module.  Here is what I found.

The HttpApplication is usually un-heard of and it works quietly behind the scenes - well not really. If you have written a HttpHandler or HttpModule or any application with some sort of complexity before - you probably already know what its all about. The HttpApplication is the base class for all ASP.NET application objects, therefore, an HttpApplication class is created for each request. However, not to get too deep into the world of the HttpApplication, I want to focus this post on the sequence of events that are executed - its pipeline.

  1. BeginRequest
  2. AuthenticateRequest
  3. PostAuthenticateRequest
  4. AuthorizeRequest
  5. PostAuthorizeRequest
  6. ResolveRequestCache
  7. PostResolveRequestCache
  8. PostMapRequestHandler
  9. AcquireRequestState
  10. PostAcquireRequestState
  11. PreRequestHandlerExecute
  12. PostRequestHandlerExecute
  13. ReleaseRequestState
  14. PostReleaseRequestState
  15. UpdateRequestCache
  16. PostUpdateRequestCache
  17. EndRequest

Any HTTP module that subscribes to an HttpApplication event must implement the IHttpModule interface, also if you look at the list you will notice that each event has a corresponding post event. i.e AuthenticateRequest to PostAuthenticateRequest. These posts events are executed after its parent event has completed, therefore, PostAuthenticateRequest is raised after the AuthenticateRequest.

BeginRequest
This is the very first event that is raised when ASP.NET responds to a request and it is always raised. Listen to this event for new requests.

AuthenticateRequest
As the name implies, this event fires on authentication of the user. Therefore, if you would like to know who is accessing your site, the "Post" of this event would be ideal to set a listener. It simply states that the request has been authenticated or the identity of the user has been established.

AuthorizeRequest
Authorizing the request is the next step right after the request has been authenticated. Trap "Post" of this event to determine if the user is authorized to access the particular resource or not.

ResolveRequestCache
Ok, it gets tricky. This event occurs after the authorize event and data is requested from cache. If the cache exist, the event handler such as a page will be bypassed and the cached request will be served. You can do several things here. Blow your mind!

PostMapRequestHandler
A post event with no "Pre" - at least no access to it. This event get raised after the request has been mapped to a handler. So if you would like to know which handler will be executed, this is the place to be.

AcquireRequestState
This executes right after the handler has been mapped to the request and it grabs the current state such as session state. Trap the "Post" event if you need to mess around with the session.

PreRequestHandlerExecute
As the name implies, this event is raised just before the request handler that was mapped earlier on is executed such as a ".aspx" or ".asmx" page.

ReleaseRequestState
At this point in time all mapped handlers have been executed and state modules will start saving state data as required.

UpdateRequestCache
Completely opposite off the above, this event is raised to signal caching modules to save response data which may be used in future request during the ResolveRequestCache phase.

EndRequest
It has to end somewhere. The EndRequest is the last event raised.

I hope this post has helped you understand how the HttpApplication pipeline flows and also help you understand which events to trap to enable you to perform some tasks at the right time.

Tags: , , ,

Development

WSDL Contract First Development

by Shawn 28. September 2011 20:30

Couple of good articles for Contract First Development

 

WSDL-First development for WCF

http://blogs.msdn.com/b/dotnetinterop/archive/2008/09/24/wsdl-first-development-with-wcf.aspx

 

WSCF - Web Service ContractFirst

http://www.thinktecture.com/resourcearchive/tools-and-software/wscf/wscf-walkthrough

 

thinktecture WSCF.blue (set of good tools)

http://wscfblue.codeplex.com/

 

Handcrafting WCF-frieldly WSDLs

http://blogs.msdn.com/b/donsmith/archive/2006/10/06/handcrafting-wcf_2d00_friendly-wsdls.aspx

Tags: , , ,

Development

A couple of great resources for Developer Cheat Sheets

by Shawn 23. September 2011 07:29

Tags: , , , , , ,

Development

How to use InternalsVisibleTo with strong named assemblies

by Shawn 16. August 2011 13:10

 

Routinely I am forgetting how to do this :) So to make life easier I am writting up a blog posting. 

When writting unit tests for VS2008/VS2010 you will may find yourself needing to access internals.  While it is possible to use the "_Accessor" classes, this is not always a friendly way to write tests (especially for complex objects and operations)

To that end, there is a nice and easy way (once you jump through a copy of configuration hoops) to handle this and that is via the "InternalsVisibleTo" attribute that lives at the assembly level.

I usually place my in the AssemblyInfo.cs file

 

[assembly: InternalsVisibleTo("MyProject.Tests")]

 

Now the trick comes when your assembly is signed with a Strong Name.  When this is the case, you will most likely receive the following error when you attempt to compile:

 

Error: "Strong-name signed assemblies must specify a public key in their InternalsVisibleTo declarations"

To fix this, we must do two things.  The first is that you must sign the test assembly, and the second is that you must include the public key in the InternalsVisibleTo statement. 

To get the public key value from the .snk file, use the sn.exe utility included in the .NET SDK. You must do two things, first, create a .snk file that contains only the public key:

 

sn -p MyKey.snk MyKey.PublicKeyOnly.snk

Then, you can extract the public key value with this command:

 

sn -tp MyKey.PublicKeyOnly.snk

This will produce a similar output:

Public key is

0024000004800000940000000602000000240000525341310004000001000100cfb8bc23b86a08e70d021dd53d3b0293e716e71015870bdcc58a0231a4228618851a83e06077f5a44f42beb2baf356ad2d344521a96b0081ed0f25f9227523e3625eda524efe1cf2e1e5e41f3693a76ec52347684b8129a4bb2d5fc49681adf33da0eecc4f81f011af4539d12abe1b4e760b5ce32d766db1012d44028381f0b4

Public key token is 2ff2b71993eeff95

Once you get this, copy the public key value (the really long one) and update the InternalsVisibleTo:

 

[assembly: InternalsVisibleTo("MyProject.Tests,  PublicKey=0024000004800000940000000602000000240000525341310004000001000100cfb8bc23b86a08e70d021dd53d3b0293e716e71015870bdcc58a0231a4228618851a83e06077f5a44f42beb2baf356ad2d344521a96b0081ed0f25f9227523e3625eda524efe1cf2e1e5e41f3693a76ec52347684b8129a4bb2d5fc49681adf33da0eecc4f81f011af4539d12abe1b4e760b5ce32d766db1012d44028381f0b4")]

Voila! You can now access the internals from your test project for strong named assemblies.

Tags: , ,

Development

Xml Formatting

by Shawn 18. July 2011 11:08

Tags: ,

Development | Utilities

Powered by BlogEngine.NET 2.5.0.6
Theme by Mads Kristensen | Modified by Mooglegiant

About the author

As an individual with a passion for technology and knolwedge I have long enjoyed being part of the computer industry as both a systems architect and infrastructure engineering.  This blog is way for me to share some thoughts. ideas, and ponderings on all of these things.

Calendar

<<  February 2012  >>
MoTuWeThFrSaSu
303112345
6789101112
13141516171819
20212223242526
2728291234
567891011

View posts in large calendar

Calendar Of Posts