SVN Per-file Access Control

I had the need to impose per-file access control for several files in our repository.  Long story short was that some files were subject to designer modification and subsequently commiting those files would break the build.  I initially experimented with 'needs-lock' property, but with auto-get-lock functionality, it ended up causing more problems (and confusion) than it solved.

I looked around for examples of per-file access control and found little.  Most posts said it can't be done, one said it could be done through modification of the authz config file and provided an example which resulted in my entire repository being locked.  Unfortunately it didn't work and locked my entire repository.  Other solutions tended toward a hook, but I wasn't interested in that route as it appears too involved and requires access to the server, something which I don't necessarily have (depending on the project team and IT/admin).

After some trial and error I found something that does seem to work.  It is simple and only involves modifying the authz config file.  Remember, order is important, so place restrictions AFTER permissions.  The format is as follows:

[repo:/path/to/file.txt]
* = access-mode

where

 - path/to/file.txt is the full path to the repository, optionally prefixed with the repository name if needed
 - access-mode is the access desired, such as blank - no access; r - read-only; w - read-write
 - * applies to everyone, you can substitute or augment with user names or groups

Example:

# disallow write access to license.lic in the /trunk/source folder
[/trunk/source/license.lic]
* = r

Note: I found that it may take a few minutes after you have saved your authz config file for the changes to actually propagate to the svn server/service (probably dependent on operating system, etc.).  If you find that the change doesn't appear to work, wait a bit and/or restart the svn server.

Microsoft Visual C++ Redistributable Runtime Hell

Microsoft has a nice knack of making problems where there are none.  C++ redistributables/runtimes is one such case.  Ever tried debugging a missing/incorrect redistributable (runtime) version issue?  Don't.

I've been unable to locate ANY meaningful description of what is a runtime compared to a redistributable and the million or so versions that show up in Add/Remove programs.  Don't take what I describe below as definitive, merely it is my best guess as to what is what, where, and why.  Redistributables/runtimes are nothing new in Visual Studio 2010, but I'm limiting my comments to that version simply because it is all that I have the patience to dwadle with at the moment.  I'm also assuming x86, although I presume the same versioning applies to x64.

Runtime or Redistributable? 
If you have the development environment installed, it is likely that you will see BOTH installed.  It appears that runtimes are installed as part of IDE service packs, redistributables are installed independently and separately from the IDE.  On a non-development machine, you will probably only see redistributables installed (which includes the runtime).

Version Please?
Would it kill Microsoft to actually include a meaningful and corresponding SP VERSION in the name?  There are SPECIFIC VERSIONS of the redistributable that correspond with SPECIFIC VERSIONS of the compiler that was used to build the actual executable.  None of this is apparent in the name, description, or listed version from Add/Remove programs.

Built with: Visual Studio 2010
Redistributable name: Microsoft Visual C++ 2010 x86 Redistributable
Redistributable version: 10.0.30319
Location: http://www.microsoft.com/en-us/download/details.aspx?id=5555

Built with: Visual Studio 2010 SP1
Redistributable name: Microsoft Visual C++ 2010 x86 Redistributable
Redistributable version: 10.0.40219
Location: http://www.microsoft.com/en-us/download/details.aspx?id=8328

What I have found is that if your executable was built with VS 2010 SP1 you MUST HAVE the SP1 redistributable installed (40219); the non-SP1 version of the redistributable installed (30319) is insufficient.
 
What a nighmare.

InstallShield Build Error -6199

Recently we started having a problem building an InstallShield installer on some of our build machines. Yes, some of them -- this is what made it so frustrating.

The error we'd see, using the standalone build is:

ISDEV : fatal error -6199: Internal build error

Not a very informative error, and not much in terms of diagnostic information out there on the web or in Flexera's KB.

I was finally able to track down the cause: character encoding. The .ism is (typically?) supposed to use a UTF-8 encoding, but there are some caveats. If you are editing the .ism directly (e.g. Notepad), your editor /may/ be encoding it in a format that the IS standalone compiler doesn't understand, an you end up w/ a -6199. Adding to the frustration is that it may compile w/ some standalone builds, including the IDE, but will fail on others for reasons unknown.

Regardless, the simplest solution is to open the offending script in the ide and then force a save. Alternatively, you can edit the file with a binary editor and remove the leading "" from the line 1.

Router Throughput Issues

We have a small office network and recently became aware of some substantial Internet<->network slowdowns. I spent some time trying to isolate the issue and found the culprit to be our Cisco VPN Router (RVL200). When the 'firewall' option was enabled, external traffic was slowed by a factor of 10. Granted the RVL200 is a low-end business-class router, but a slowdown of 10x is beyond the pale.

Our Internet connection speeds are rated at 20/1.7 MB/s by our ISP. Here's my findings:

ISP: Cox, cable broadband rated at 20/1.7 (download/upload).
Broadband Cable Modem: Motorola Surfboard SB5100, firmware version 2.3.6.0
Primary router: Cisco/Linksys RVL200 VPN Router, firmware 1.1.10.1
Router: Linksys Wireless G Broadband Router WRT45GS v7, firmware 7.50.8
Router: Netgear Wireless-G Router WGR614 v10, firmware 1.0.2.4_39.0.39NA

Speed test: http://www.speakeasy.net/speedtest
My location: Las Vegas
Test location: Los Angeles
Methodology: Asus netbook computer, Windows XP SP3, physical wired connection to devices, nothing else connected. Tests run a couple of times to confirm consistency.

Test 1: Surfboard: 14.13/4.85
Test 2: RVL200 (firewalled): 2.46/2.79
Test 3: RVL200 (not firewalled): 20.04/5.32
Test 4: RVL200 (firewalled, other settings disabled): 2.35/2.88
Test 5: WRT54GS (firewalled): 20.39/4.92
Test 6: WGR614 (firewalled): 20.8/5.41

Conclusion: the RVL200 doesn't have a firewall, it has a *brick* wall. We've since moved to a Sonicwall appliance for our VPN, so the RVL200 is looking for a new home...

Unable to Connect to SQL Server While VPN Active

I've had the following problem for quite some time now, and finally resolved. At first blush, it seems like a simple enough issue to resolve, but in my particular case, it wasn't.

Basically what happened is that I have an instance of SQL (Express) installed on my primary development machine that is used as part of design, development, and building of the various applications I'm working on. I also have need to connect to a particular customer network via VPN (Aventail/SonicWALL). Everything was working fine until a few months ago when the customer updated the VPN client (from 9? to 10), at which point I was no longer able to access my SQL instance through trusted connection.

For example, if connected to the VPN and attempting a command line query, I'd see the following:

C:\>osql -S localhost\sqlexpress -q -E
Login failed for user ''. The user is not associated with a trusted SQL Server
connection.

In checking the event log, I'd see the following error:

SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed. [CLIENT: nnn.nnn.nnn.nnn]

If I disconnected the VPN, the above works as expected (no error).

?

My first conclusion was that the new VPN client was tunnelling ALL traffic through the appliance, and local requests back to my machine, and therefore SQL was considering the request as 'remote' and denying it. I tweaked the necessary SQL properties to allow remote connections -- nada.

After spending a lot of time trying to diagnose, I temporarily gave up and just resolved that I'd either be able to do VPN work or SQL work, but not both simultaneously.

Not satisfied with that 'solution', I resolved to spend more time on it. I'll leave out the countless things that I did try and didn't work and mention what I did find that actually solved the problem for me -- hopefully it will help someone else:

I started looking at the SQL configuration a little more closely (Start Menu\Programs\Microsoft SQL Server 2005\Configuration Tools\SQL Server Configuration Manager) and noticed some differences from some of the other typical SQL installations I have floating around. Specifically:

Under SQL Server 2005 Network Configuration: all protocols were enabled.
Under Aliases, there were several aliases using the tcp protocol.

I reset the above to coincide with what appears to be the default configuration:

SQL Server 2005 Network Configuration
  Shared Memory - Enabled
  Named Pipes - Disabled
  TCP/IP - Disabled
  VIA - Disabled

Deleted all SQL Native Client Configuration Aliases.

After that, my VPN/SQL issues were resolved! I'm not exactly sure what was the cause (protocol or alias), but a little more post-fix experimentation leads me to believe tha that the aliases were the problem. How that relates to the updated VPN client, or if it was purely coincidental, I don't know, but it is fixed and I'm satisfied!