Developer Solutions for Web and Other

cscript adsutil.vbs set w3svc/MaxConnections 40

Transactions are used to add the Rollback functionality to calls, Rollback meaning the if an exception or something is thrown your call will not be executed (Commited is the term used for this). Another benefit of using Transactions is that you can group calls together, if somethign happens to one call then all of calls in that group can also be rolled back. This type of feature is particularly useful when taking user input and saving to DB, you may not want anything to get written to the DB is some error occurs on the client. .NET provides us with the System.Transaction assembly, it's not completly straight forward to use but it does hide alot of the underlying complexities. A couple of things I've learned about using System.Transactions or more specifically the System.Transactions.TransactionScope class: The safest way to use it is with the using clause. Always call Commit() before the end of the using. The optional TransactionScopeOptions enum parameter in the constructor de...

I always find this topic a great source of confusion each time I get back to it. I've just across various Exceptions being thrown in my application, FileNotFoundException and AccessViolationException. The first caused because the application cannot location a Type that one of my assemblies references and lives in another assembly. The second is caused by that same file being found but it's locked by another process i.e. something else is reading or has read and not released the assembly. Both of the above were caused by messy code which used a simple Assembly.LoadFile(...). Looks to me like you should never use this method, I'll explain more below. There are many ways to create an Assembly instance. Assembly.Load(assemblyName); Assembly.LoadFile(assemblyName); Assembly.LoadFrom(assemblyName); or even AppDomain.Load(assemblyName); There are some subtelties however, some consequences which may later cause issues e.g. the assembly you've loaded is locked. Assembly.LoadFile...

Custom Action The Custom Action is added to the Setup Project, select the Project node and hit the Custom Action button. This allows you add an Action to a particular phase in the Installation. But first you must create the Custom Action. To Add a Custom Action you must first have a Custom Action created, this is usually in the form of a Installer Class, this should be created in a seperate project, the Installer Class is actually one of the File Templates in the C# Projects. So it's File->New Project and select Visual C# Projects. Then add a Class Library, this will prompt you for the Class Library Types , select "Installer Class". Walkthrough - Creating Custom Action (msdn). Also here's a more comprehensive document on Setup/Installer implementations, it delves into the Registry etc Getting Started with Setup Projects (SimpleTalk). Visual Studio Setup Projects and Custom Actions (Simple Talk). Create your Installer Class and then add it as a Custom Action to the ...

Transactions are used to prevent your application from getting into an unknown state. Transactions work on services which register with the Transaction service such as Database calls. It's useful where you cannot be sure that the resource (DB) will remain available while some data is changing and if the resource for some reason is made unavailable during a call then what happens to the data, well the Transaction should Rollback your Data so the app remains in the state it was before the data was sent. Transactions in .NET are implemented with System.Transaction.TransactionScope class. In the background this uses COM+. Wrap your DB call in a new TransactionScope instance, when the functionality is finished call TransactionScope.Complete(), then TransactionScope.Dispose(). If the execution makes it to these calls then your changes will be applied, if not your changes will be Rolled-back by the Transaction and you app will remain the same as before the call started. MSDN Video http://...

With installer issues it's always difficult debug problems. If it's the Installer itself i.e. work done in the setup.vdprj itself then you maybe in a spot of bother. There are some logging options which are available to you.The other problem you may have is with your Custom Action if you have one. This maybe easier to diagnose, asyou can use the Visual Studio Debugger to attach but this in itself is not always easy todo. If you have problems with your installer itself and not the Custom Action then try this: You can also Log installer actions by activating the installer logging, this is done through a registry entry, http://support.microsoft.com/kb/223300 . All your doing is adding a "String Value" named "Logging" and a value "voicewarmupx" to the registry entry HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer I've done this and found some useful info but it's not that easy to read, at least it tells you the command that was...

The ProjectAggregator is a dll that is required in order to use Packages developed with Visual Studio's 2005 Extensibility SDK. The projectaggregator.dll must be dropped into the C:\Program Files\Microsoft Visual Studio 8\Common7\IDE directory, if it doesn't exist then the end user will not be able to open projects in Visual Studio 2005 that are associated with your Package. Microsoft provide an installer ProjectAggregator.msi which does this work for you. The problem with this is you either tell all your clients to run the projectaggregator.msi themselves after or before installing your Package or else you include the installation of it in your own installer. The second option is of course the right one, as who would expect customers to run more than one installer. To include this in your installer however you need to create what is known as a BootStrapper project. The Bootstrapper is another installer that wraps the installer you actually wish to run. The idea is you include ...