Silverlight : Could not load file or assembly 'System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' or one of its depend

Very irritating!

and very similar to here:
http://bartwullems.blogspot.com/2010/08/could-not-load-file-or-assembly.html


Solved as follows:

cd C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0

gacutil /i System.Windows.dll

gacutil /i System.Core.dll

Net.Tcp WCF requires clientaccesspolicy.xml be available from IP, not hostname

Testing a new Net.Tcp WCF service, I got the following error:

"Could not connect to net.tcp://X:4502/XService. The connection attempt lasted for a time span of 00:00:00.4270427. TCP error code 10013: An attempt was made to access a socket in a way forbidden by its access permissions.. This could be due to attempting to access a service in a cross-domain way while the service is not configured for cross-domain access. You may need to contact the owner of the service to expose a sockets cross-domain policy over HTTP and host the service in the allowed sockets port range 4502-4534."

Although this is a very common error, in our case, it was not fixed by the obvious solutions:

1. clientaccesspolicy.xml was already available. I verified that through the browser.
2. clientaccesspolicy.xml already had the correct contents allowing port 4502.

It turned out that while clientaccesspolicy.xml was available via our server hostname, it was NOT available via the server IP address.

Even if the Silverlight client is configured to access a net.tcp WCF service using a valid DNS name, it still uses the IP address of that DNS name to load the clientaccesspolicy.

This happens EVEN IF it has already loaded the very same clientaccesspolicy.xml through the DNS name.

In our case at least, IIS7 by default does not allows access by IP for a site that has already been configured for for a DNS name.

So I added a new site in IIS Manager, bound to the IP address, pointing to the same folder already containing our clientaccesspolicy.xml file.

But, this new site must be bound to the internal IP (e.g. 192.168.1.xxx), NOT the external IP (e.g. 88.77.66.55).


After I discovered the problem I found this:

http://blogs.msdn.com/b/silverlightws/archive/2010/04/09/policy-file-for-nettcp.aspx

Net.Tcp WCF service requires 'Integrated' managed pipeline mode, not 'classic' mode

We built and successfully tested a Net.Tcp WCF service. But when deploying it to an off-site server for further testing, we discovered the IIS worker process was crashing.

In the event log, we got plenty of these:


Source: ASP.NET 4.0.30319.0
EventID: 1088
Description: 0x8000ffff Catastrophic failure


and some of these:


Faulting application name: w3wp.exe, version: 7.5.7600.16385, time stamp: 0x4a5bcd2b
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x00000000
Faulting process id: 0xfe8
Faulting application start time: 0x01cb429f60c2c986
Faulting application path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
Faulting module path: unknown
Report Id: f85bf6d3-ae92-11df-a403-00219b00a9ca


We had to issue an 'iisreset' command from command line to bring it back.

It turns out, the offsite servers were running our application using a 'Classic' mode app-pool. But during development, we used 'Integrated' managed pipeline mode.

Changing the offsite servers to 'Integtated' seemed to fix the problem.

ExecuteReader: Connection property not initialized

This is an inaccurate error message!!

Despite what the error message says, the following error can be caused by not setting the 'CommandText' property of the SqlCommand object:

System.InvalidOperationException: ExecuteReader: Connection property has not been initialized.

I noticed this while working with transactions.

In my case it was NOT caused by the 'Connection' property

Cygwin SSHD, Remote Tunnel, GatewayPorts

When opening a remote tunnel over SSH, I need to allow clients on machines other than the SSHD host access the port that has been opened.

To do this, the client needs to specify this option. e.g. in putty, set the 'Remote ports do the same' option.

AND

the SSHD server needs to have 'GatewayPorts' enabled in /etc/sshd_config

Subversion: Trimming old commits, keeping revision numbers intact.

Our repository is getting quite large. Some time ago, we reorganised our repository, and none of the history before that reorganisation is really that important.

So, I decided to do a 'dump' of the repository from the earliest required revision to HEAD, and the load that into a fresh repository.

But I got the following warnings:
"Referencing data in revision [X], which is older than the oldest"
and
"Loading this dump into an empty repository will fail."

So I retried this a few times, moving back the 'start' revision until I no longer got this error. Luckily I didnt have to go back much further.

I then did a 'load' cammand of this new dump back into a new repository.

Next thing I noticed was that this new repository, while functionally correct, had different revision numbers. But the old revision numbers are referenced in our revsion tracking system, and in comments throughout out the version history.

How do I load back my dump file, with a starting revision matching the original repository?

I found I could put together a tiny script that inserts a series of trivial commits to the repository, filling in the required version numbers. Then when loading in my dump file, it's commits match the revision number of the original repository.

But since the new repository is not empty when loading the dump file, I need to set the UUID of the new repository to match the old repository, using --force-uuid

Its not the most elegant solution, but seems to work.

The following are the commands I used:

1.
svnadmin dump \SVN\ROOT -r 1282:HEAD > ROOT_1282.dump

2.
svnadmin create \SVN\ROOT2

3.
svn co file:///c:/SVN/ROOT2 ROOT2_WC

4.
echo 0 > ROOT2_WC\zzz

5.
svn add ROOT2_WC\zzz

6.
# NOTE: the following commits from r1 to r1280, since r1281 happens
# in step 8. Then the dump file starting revision (original r1282)
# matches the next revision in this new repository.
for /L %n in (1,1,1280) do (
echo %n > ROOT2_WC\zzz
svn commit ROOT2_WC\zzz -m "empty commit replaces original")

7.
svn delete ROOT2_WC\zzz

8.
svn commit ROOT2_WC -m "removing dummy file used for empty commits"

9.
svnadmin load --force-uuid ROOT2 < ROOT_1282.dump

SQL Server Transaction Log too big...

USE MyData
GO
DBCC SHRINKFILE(MyData_log, 1)
BACKUP LOG MyData WITH TRUNCATE_ONLY
DBCC SHRINKFILE(MyData_log, 1)
GO