My application references several DLL’s. Some of these DLL’s get their data from Web service. You might already know that the WebRefrence URI will be saved in config file. This config file will also be available in DLL’s bin folder. But when we add reference to the DLL in EXE, these DLL specific config files are lost. Therefore, before you build & send the EXE, you need to make sure that the given WebService Url is reachable by the target PC.

Recently, I had a problem with this. I package my application and deliver it to an external user. The user’s webservice url is different from what I configured which building. Practically, it is not possible for us to build the app for every customer. So, there needs to be a way to fix this issue. Yes. there are several ways of course. When I googled, I could find 2 possible solutions.

1. Copy DLL.config file from DLL’s bin folder to EXE bin folder.

2. Merge the content of DLL.config file in EXE.config file.

The former approach is simple. But we should never forget it. The later approach is complex but a programmer can do it easily.

My deep thought is “why Microsoft forgot to think about this issue while upgrading VS versions?”, “Is this by design?”, “There could be many with similar issue. Is there no other way to automatically add DLL.config file in EXE folder.?”

Yes. There is a third workaround. Why not use Pre-Build events of your project? It’s quite simple and removes all the hassles. Here is the way to use it.

1. Open your EXE project properties & switch to “Build Events” tab

Pre Build Events - Properties Window

2. Write the below copy command in it.

copy $(SolutionDir)<>\bin\Debug\<>.dll.config   $(TargetDir)

3. Save it & Build the project. Viola.. you can now see your DLL.config file automatically included in your EXE bin folder. Now your customers can be advised to change the reference url in these config files on their own. Isn’t it simple & easy to do?

Enjoy !!!!.

Every business application requires a about box. You can display static values here or retrieve them from your assembly and display at runtime. There also many ways to deploy your application to the end-user. In case, you use click-once, then you may want to display the publish version rather than the assembly version in your about box.

Here, I am explaining you how to retrieve such information from your assembly and version from your click-once publish and display at runtime.

Assembly assembly = Assembly.GetExecutingAssembly();
// name, description and more
object[] attributes = assembly.GetCustomAttributes(true);
foreach (object attribute in attributes)
{
	if (attribute is AssemblyTitleAttribute)
		lblAppName.Text = ((AssemblyTitleAttribute)attribute).Title;
	//similar to this, you can also extract company name, copyright etc.
}

if (System.Deployment.Application.ApplicationDeployment.IsNetworkDeployed)
{
	//This application was deployed using click-once publish. So display publish version
	lblVersion.Text = System.Deployment.Application.ApplicationDeployment.CurrentDeployment.CurrentVersion.ToString();
	hypUrl.Text = System.Deployment.Application.ApplicationDeployment.CurrentDeployment.UpdateLocation.OriginalString;
}
else
{
	// assembly version
	AssemblyName assemblyname = assembly.GetName();
	Version assemblyver = assemblyname.Version;
	lblVersion.Text = assemblyver.ToString();
	hypUrl.Visible = false;
}

Today, I bought a new 16GB USB drive to watch movies above 4GB size in our HD TV. The default file system of my USB device was FAT32. While trying to copy the file (4.67GB size) into my USB device, I received an error. “File size is larger than the maximum size of the file system”. Later when I searched on internet I found that the maximum size supported by FAT32 system is just 4GB. Google search couldn’t return a table like the one below too. So, here is the easy table to help everyone.

The below table is applicable only to file systems supported by Windows. I am planning to upgrade this table to show all types of file systems in near future.