UltiDev Cassini is being retired and replaced by
UltiDev Web Server Pro (UWS).
UltiDev Cassini for ASP.NET 4.0 will not be released. Please use
UWS instead.
Release Log
July 12, 2008.
Added Visual Studio 2008 Support. Runtime tested with
ASP.NET 3.x.
Summary of New Features
New Features Details
- Visual
Studio 2008 Support
Visual Studio 2008 support adds UltiDev Cassini Web
Server 2.0 to the list of Setup project
prerequisites in VS 2008. Unlike Visual Studio 2005,
VS 2008 does not have to be installed in its default
location for the installed to find it.
Visual Studio 2008 developers can target 3.5, 3.0
and 2.0 versions .NET Framework,
except WCF services (ASMX still works).
-
Cassini 2.0 compatibility with ASP.NET 3.x verified
UltiDev Cassini Web Server 2.0 itself has not
been changed or updated in this release. We just
tested existing engine with ASP.NET 3.5 applications
and web WCF services. We established that current
web server works with ASP.NET 3.5 and 3.0 very well,
including supporting new language features, like
Lambda expressions, and new ASP.NET features, like
built-in AJAX support.
Unfortunately, while ASMX web services are still
supported, WCF services are not due to the
bug in WCF.
When registering ASP.NET 3.x applications manually
using Cassini Explorer, specify 2.0 as a target
ASP.NET version.
February 10, 2007. General
Availability Update: Better Stability and Wider
Compatibility.
Summary of New Features
Summary of Bug Fixes
New Features Details
- Support of 64-bit versions
of Windows, including Vista x64, Windows XP Pro x64
and Windows 2003 64-bit.
UltiDev Cassini Web Server could not be installed on
64-bit versions of Windows. We added support of
Windows Vista x64, Windows XP x64 and Windows 2003
Server x64.
- Creating
Windows Firewall exceptions for UltiDev Cassini
service processes.
Client browsers often failed to reach applications
running under UltiDev Cassini because of the Windows
Firewall blocking the incoming HTTP traffic.
Starting with this release UltiDev Cassini creates
firewall exceptions for Cassini Server service
processes. Please note two important considerations:
- Windows Firewall exceptions are created only
for inside-the-LAN (Intranet) traffic. To allow
Internet traffic through UltiDev Cassini, the scope
of Windows Firewall exceptions for UltiDev Cassini
needs to be changed.
- UltiDev Cassini running as a command line program
may still be blocked by Windows Firewall depending
on which executable is launched.
Bug Fixes Details
- Missing Windows
Scripting Host component caused cryptic error
message.
Windows Scripting (WSH) component is by default
present on most of windows systems. However, if it's
unregistered or removed, UltiDev Cassini would fail
to install with hard-to-decipher error message. To
fix the issue UltiDev Cassini Web Server installer
will abort installation if WSH is not found on the
computer and will provide information of where the
WSH can be downloaded from.
- UltiDev
Cassini Web Server installation failed if metabase
file had no registered application entries in it.
Before this release UltiDev Cassini metabase file
should have either contained one or mroe registered
application entries, or should not exist. Cassini
metabase file with zero entries caused various
Cassini Server components to crash. The issue was
fixed in this release.
-
Frequent subsequent modifications of the
metabase file caused applications to fail get loaded
on slow PCs.
Modifications to UltiDev Cassini metabase file
causes UltiDev Cassini Web Server to unload and then
reload again all applications. The operation used to
be asynchronous and therefore several modifications
to the metabase file made before UltiDev Cassini
finished to reload applications caused applications
competing for the same IP port (port already bound
error entries in the windows Even Log). This issue
was fixed by synchronizing application reload calls.
-
Registered application with invalid physical path
caused UltiDev Cassini Web Server service failure to
start.
Registering an application with invalid physical
path caused UltiDev Cassini Web Server process to
crash and stop serving all applications. Issue fixed
by adding the check for whether application folder
exists.
-
Uninstallation of UltiDev Cassini for ASP.NET
1.1 didn't make Cassini for ASP.NET 2.0 pickup the
load.
When UltiDev Cassini Web Server products for ASP.NET
1.1 and 2.0 are deployed side-by-side, uninstalling
Cassini for ASP.NET 1.1 should have triggered
Cassini for ASP.NET 2.0 to load ASP.NET 1.1
applications, which was not happening. Issue fixed
by restarting Cassini for ASP.NET 2.0 service after
Cassini for 1.1 was uninstalled.
August 4, 2006. GA Update Release
Summary of Bug Fixes
Bug Fixes Details
-
GoToApplication.aspx of Cassini Explorer used
incorrect hostname as a base for redirected URL.
Before this release Cassini Explorer's
GoToApplication.aspx and
CassiniConfigurationService.asmx always returned
applications' URLs based on the server's machine
name. For example, pointing your browser to http://domain.com:7756/GoToApplication.aspx?ApplicationID=<someGuid>
would redirect to http://servermachinename:<ApplicationPort>/
instead of http://domain.com:<ApplicationPort>/.
This created problems when accessing applications
from outside the network. In this release the
address in applications' URLs generated by Cassini
Explorer will be the same as in GoToApplication.aspx
and CassiniConfigurationService.asmx URLs.
- Cassini for
ASP.NET 1.1 upgrade was broken due to GAC
installation issue in .Net Framework.
Previous release of Cassini Server for ASP.NET 1.1
was incorrectly upgrading from previous version -
the first General Availability release. Cassini
Request Processor assembly failed to register in GAC
during upgrade installation. This release will
upgrade from any previous version.
-
Cassini for ASP.NET 1.1 was not releasing memory
allocated for ASP.NET applications' AppDomains.
All previous versions of UltiDev Cassini Web Server
for ASP.NET 1.1 had a memory leak that was occurring
when Cassini metabase file is changed. The reason
for that is Server.Stop() method from original
Cassini Web Server Sample was not unloading
AppDomain created for each application.
- Cassini
Configuration API Help file is reinstated as a part
of the Cassini Explorer installation package.
Configuration API Guide was missing in the previous
release even though the shortcut was created in the
Programs group menu.
-
Cusom Setup.exe bootstrapper of Cassini for
ASP.NET 1.1 package is now using TEMP folder instead
of its execution folder when extracting Cassini
components before installation.
Setup.exe custom bootstrapper for ASP.NET 1.1
Cassini distribution was using its own folder to
extract Cassini for ASP.NET 1.1 component before
installing them. That could potentially lead to
problems when installing applications distributed
along with UltiDev Cassini for ASP.NET 1.1 from a
network share.
July 10, 2006: General Availability Release
Summary of New Features
Summary of Bug Fixes
New Features
Details
- New Cassini
distribution model. Before this version UltiDev
Cassini was packaged as a Merge Module. After
extensive testing we determined that Merge Module
concept provides for poor upgradeability of
components. To give an example, if application A
installed Cassini build 100, and application B
installed upgraded Cassini build 200, both will work
fine using build 200 until application B is
uninstalled. Because of that Cassini components were
made to survive their bundled applications'
uninstallation. This ensures that the latest
compatible version of Cassini server remains after
multiple applications using UltiDev Cassini get
installed and uninstalled. Even though uninstalling
your application will not automatically uninstall
UltiDev Cassini components, user will be able to
remove UltiDev Cassini from Add/Remove Control Panel
applet. Users of previous versions of Cassini,
please read latest version of
Cassini Developer's
Guide for the information on how to redistribute
your ASP.NET with UltiDev Cassini using custom
Setup.exe bootstrapper.
- Windows Vista
compatibility. Windows Vista as of Beta 2 release
was not creating ASP.NET Temporary Files folder for
.NET Frameworks - a folder ASP.NET requires to be
present at runtime. Even though it may get fixed
before Microsoft releases Vista, we create the
folder ourselves if it doesn't exist.
- NOBROWSER
command line parameter for Cassini Server
executable. When running Cassini server as a regular
Windows executable (in contrast to running it as a
background service), Cassini used to always launch a
browser showing default application page. NOBROWSER
parameter lets Cassini start hosting an application
under current logged user account, but will not pop
up the browser.
- UltiDev Cassini
Programs group icons are for all users now. Before
this version Programs group icons were created by
Cassini installer for only user who launched the
installation. This version makes icons visible to
all users of the system. This is important for
Windows Vista which often temporarily gets elevated
into more powerful user account for program
installations and other administrative tasks.
Bug Fixes
Details
- SERVER_NAME server
variable value. Cassini (including the one from
Microsoft) used to always return server's IP address as
a value of SERVER_NAME server variable, while IIS would
return hostname if the requests was for hostname, and IP
address if request was for an IP address. Particularly
this lead to difference in WSDL binding addresses when
WSDL is requested for web services under Cassini. Fixed.
- Request.MapPath() method.
Before this version passing "dir/" or "dir" to
Request.MapPath() method would cause Cassini 1.1 to
return the same value without the trailing slash, while
IIS and Cassini 2.0 would return slash if it was passed.
That caused incompatibility issues between Cassini and
IIS. Fixed.
- Cassini Explorer
port number value validation. It was often impossible to
save application's configuration after editing its
settings in Cassini Explorer due to a bug in ASP.NET
range validator. Fixed.
March 14, 2006: Release Candidate 1
Summary of New Features
Summary of Bug Fixes
New Features
Details
- Applications can be kept pre-loaded in memory
for quick first-page response.
Since UltiDev Cassini Web Server is likely to be
used in a relatively low-load scenarios, it's likely
applications could often sit idle and thus be
unloaded by ASP.NET to preserve memory. In low-load
scenarios users are more likely to face long
first-page-served time due to idle application need
to be loaded, than high-traffic sites where
applications are kept in memory by lots of requests.
To counter perceived poor performance, RC1 added an
per-application option to keep applications loaded
in memory at all times. This ensures very quick
application response even if application is not
heavily used. The tradeoff is higher system memory
consumption.
- Registering and un-registering applications with
Cassini does not require writing code anymore.
If you are a developer who ships an application
bundled with UltiDev Cassini Web Server, your
installer will have to register the application with
UltiDev Cassini Web Server as a part of the
installation process, and unregister as a part of
uninstallation. Before RC1 that involved writing a
custom installer steps code for your setup project.
RC1 added a typical register/unregister code to the
CassiniConfiguration assembly, which can be used for
your setup project custom install steps to register
applications with UltiDev Cassini Web Server without
writing any code.
- Web Services under
Cassini don't need to have
static ports anymore.
It's highly recommended that your installer allowed
UltiDev Cassini Web Server to find and assign free
TCP port to your application. There was always a
port-independent way to redirect a browser to your
web application. But if you used Cassini to host a
web service, your web service client was unable to
find out programmatically the exact URL of the
your service. RC1 added a web service to the Cassini
Explorer that returns either port, or the whole
application URL for a given application ID. After
you installed Cassini RC1, look at
http://localhost:7756/CassiniConfigurationService.asmx
to find out how your web service clients can
retrieve application URL information. Please note
that Cassini application configuration changes
trigger brief downtime as Cassini reload
applications. If your web service call does not go
through, catch the exception and retry the call a
few seconds later.
- Cassini Explorer home page updates state of
running apps without Refreshing the page.
Cassini Explorer home page displays state of
registered applications (Running or Not Running).
Before RC1 it took hitting browser Refresh to see if
state has changed. RC1 added an Ajax-based callbacks
that update application state information every 30
seconds without reloading the entire page. Please
note that automatic state updates do not change the
list of application - only state info is updated. If
applications were registered or unregistered,
browser Refresh action is required to update the
list of applications on the application summary
page.
- TCP/IP settings in Registry updated during
Cassini installation for best performance.
Windows XP comes with TCP/IP settings not tuned for
web server usage. This may lead to very low
throughput under stress load, because within seconds
Windows will start running out of ports that can be
used to accept incoming connections. RC1
installation updates Windows Registry so that it
never runs out of ports even under stress load.
Please note that it requires system reboot for
modified settings to take effect. UltiDev Cassini
Web Server installation does not trigger system
reboot since in most cases UltiDev Cassini Web
Server is unlikely to be used under heavy load. If
your application is expected to serve dozens or
hundreds requests per second, your application
bundled with Cassini needs to trigger system reboot
after installation.
Bug Fixes Details
- Memory leak in
Cassini 2.0 is fixed.
UltiDev Cassini Web Server 2.0 Beta 1 was leaking
memory due to the bug in original Cassini code.
(Cassini 1.1 Beta 1 does not have this problem). The
issue is fixed in RC1.
- InstallState file corruption in
Cassini 2.0 when
deploying multiple Cassini applications side-by-side
is fixed.
Multiple applications bundled with UltiDev Cassini
Web Server 2.0 Beta 1 deployed side-by-side on the
same system might have prevented last application
from being uninstalled correctly. The issue is fixed
in RC1.
- Application Event Log settings changed during
Cassini installation to avoid OS running out of
space.
UltiDev Cassini Web Server uses Windows Application
Event Log quite extensively for logging and error
tracking purposes. Windows XP default settings cause
applications to crash if Event Log is full. Cassini
RC1 installer changes default application log
settings to significantly increase the storage size
for application events, and to overwrite oldest
events once event log runs out of space.
December 24, 2005: Beta 1 - Initial Release
|
 |
