This article shows how to define a class, private, public and static variables.
Tuesday, December 18, 2012
Monday, March 5, 2012
While working on a xslt project, got to know about this xslt file which lets you output the xml as is. This is excellent for debugging purposes to see what xml the xslt file gets to work on.
<xsl:output method="xml" indent="yes" />
<xsl:template match="/ | @* | node()">
<xsl:apply-templates select="@* | node()"/>
Tuesday, May 31, 2011
As people have already noticed that in .Net 4.0 web project, there are multiple versions of Web.config file such as Web.Debug.config and Web.Release.config. Developers can also add more files like this for e.g ConnectionStrings.config can also have ConnectionStrings.Debug.config and ConnectionStrings.Release where Debug and Release are Configuration of a project.
Lets look at the scenario where we would want to add ConnectionStrings file version so it uses the proper config file depending on the project build configuration type.
Step 1 – Add new ConnectionString files to your project
Add 4 configuration file to your project as follows:
File for debug and release contents will look like following:
<?xml version="1.0" encoding="utf-8" ?>
<connectionStrings xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform" xdt:Transform="Replace">
<add name="MyConnectionString" connectionString="Address=[server],1433;Database=[database];UID=[user];PWD=[password];"/>
You can add as many connection strings depending on which build type you want them to be associated with in its respective file. Like ConnectionStrings.Debug.config will contain connection strings to our development environment which we want to use in “Debug” mode.
ConnectionStrings.Release.config will contain connection strings to our production environment when we build the project for “Release”.
For now, file ConectionStrings.Template.config contents don’t have to have any connection strings in it since it’ll be used as a template to create ConnectionString.config file. You can add connection string in this file if they are not specific to a project build type and you always want them to be there. But for now, it’ll be empty like following:
<!-- connection strings -->
Step 2 – Update project file
We are going to add some xml to the project file so Visual Studio build knows how to associate different ConnectionString files together. Also, Visual Studio will show connection string files in a nested tree in solution explorer.
We’ll add some build tasks so Visual Studio uses the proper ConnectionString file depending on the project build type.
Right click on project node in solution explorer and choose unload project option. This allows you to open project xml file and update it. Right click again and choose Edit [Project.csproj]. You’ll notice that xml file for project will appear for edit.
Under /Project/ItemGroup, Add Following:
<None Include="App_Config\Server\ConnectionStrings.Template.config" />
This tells visual studio to show debug and release files for connection string nested under ConnectionStrings.Template.config node in solution explorer. Please note that we are assuming that connection string config files are saved under /[ProjectFolder]/App_Config/Server folder.
Next, to the very bottom of project xml file under /Project, below <import> tag(s) add:
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll" />
This lets you use TransformXml task which we’ll use below.
Under this “UsingTask” node add:
<Target Name="ConfigConnectionStrings" Condition="Exists('./App_Config/Server/ConnectionStrings.$(Configuration).config')">
<Delete Files="./App_Config/Server/ConnectionStrings.config" />
<TransformXml Source="./App_Config/Server/ConnectionStrings.Template.config" Destination="./App_Config/Server/ConnectionStrings.config" Transform="./App_Config/Server/ConnectionStrings.$(Configuration).config" />
<Copy SourceFiles="./App_Config/Server/ConnectionStrings.Template.config" DestinationFiles="./App_Config/Server/ConnectionStrings.config" />
<CallTarget Targets="ConfigConnectionStrings" />
The above piece tells Visual Studio to delete ConnectionStrings.config file so we always have a new copy created whenever we build the project and there are no read/write issues. Then it instructs the project build to transform the appropriate connection string file based on project build type.
It also adds “BeforeBuild” target which copies the empty ConnectionStrings.Template.config file as ConnectionStrings.config which we’ll fill based on the project build type.
Right after the copy, it directs the project build to call the ConfigConnectionStrings target which performs the delete of older ConnectionStrings.config copy and does the transformation.
Now once you save your project file and right click on project node in solution explorer, choose “reload project” option to load the project along with all its files in solution explorer.
Step 3 – Add external ConnectionString file reference to web.config
To keep connection strings outside of the web.config file, we have to add the following line under /configuration node.
<connectionStrings configSource="App_Config\Server\ConnectionStrings.config" />
Step 4 – Excluding ConnectionStrings.config file from project
Last but not least, we have to exclude ConnectionStrings.config file from the project list in solution explorer so it can be deleted/created by project build. Since we are using svn at work, we have to do an additional step to ignore the file from svn. If you are using AnkhSvn Visual Studio plug-in, you can right click on ConnectionStrings.config file and go to Subversion > Ignore > Ignore File (ConnectionStrings.config) option.
That’s it folks, now when you build the project, you’ll see a new copy of ConnectionStrings.config file created with your connection strings based on your project build type.
Friday, September 24, 2010
Recently I was involved in an assignment which involved using messagequeue. We ended up implementing both Amazon and Azure as Queue providers. With libraries available for both of them, its very easy to integrate both in application.
Amazon provides SDK for many platforms such as Java, PHP, Python, Ruby and .Net. SDK makes it very easy to incorporate any cloud computing service in your application.
Three simple Steps to incorporate Amazon Queue in .Net apps:
- Download the SDK
- Reference AWSSDK.dll in your project
- Write code (Found the SDK samples to be very helpful and easy to understand)
Just like Amazon, Azure provides SDKs for Java and .Net. I liked Amazons approach that they give you the code samples with SDK. Azure does give you some code samples but they don’t include samples for Queue and not for every services which it provides. To get all the samples, you can get them from here (Make sure to download samples which are marked as Additional C# Samples)
Same with Azure, simple steps to incorporate
- Download the SDK from here .
- Reference Microsoft.WindowsAzure.StorageClient.dll in your project
- Write code
One thing I noticed is that Queue names has to be in a certain format else you’ll get an exception response. Naming conventions are found here.
Enjoy Cloud computing!
Monday, September 13, 2010
Was wondering if it’s possible to remove the Navbar and have found a video post which describes all you need to do. The css update which you need in your HTML is as follows:
Video post link: http://blogger-templates.blogspot.com/2005/01/remove-navbar.html
Wednesday, September 8, 2010
A friend of mine was building a WCF service with windows authentication and ran into a couple issues. He found the solution and posted the solution at http://stackoverflow.com/questions/1367653/wcf-service-windows-authentication
Tuesday, September 7, 2010
If you right click on a project in Visual Studio (2010), under application tab there is a property called Default namespace. Both C# and VB.Net treat it differently.
In VB.Net, by specifying default namespace project property, it is default root namespace of your library if you don't specify any for your class which is really what it should do I think. For instance, if you had a following class in file MyClass.vb and it had no namespace defined and your default namespace in project setting was set to MyApplication, you will access this class as MyApplication.MyClass.
In C#, default namespace property is only used as a namespace template name when you create new files. It does not effect the root namespace of your library (dll). For instance, If default namespace was set to MyApplication with following class then your class will end up in no namespace. To access your class in other projects, you just have to type MyClass which is not the solution one would want to keep, since all classes from this library will end up in default namespace (no namespace).