I have run the VMware Standalone Converter now from several different machines. Each time I get an error that the file
C:\ProgramData\VMware\VMware vCenter Converter Standalone\ssl\rui.crt cannot be opened.
The file is always there but cannot be accessed. The file properties always show Administrators have full access, and my current user is an administrator. Never the less, just set your logged in user to have full access to the folder and all will work fine.
I’ve been using Jungle Disk for nearly three years now for reliable, easy, and inexpensive cloud storage. The software uses Amazon S3 storage or their own Rackspace storage. Since I currently run five machines at home and one at work the network drive that Jungle Disk mounts is great for storing large files. It can also be configured to do automatic backups. For things that change everyday, I also run Windows Live Mesh.
Recently on my new Vista machine the Jungle Disk service would just hang in the starting state. I tried reinstalling several times with the same result. I resorted to the Jungle Disk help desk.
The first response was disappointing: make Jungle Disk an exception in the firewall and make sure ports 80 and 443 are open. Since none of the other machines running McAfee had this set, I didn’t think it would help. But of course I tried it to no avail.
I specifically asked how to remove all program information before the installation. Every time I tried reinstalling the software I was never asked for my Amazon S3 information. I had assumed it was a registry entry, but in fact for Vista it is stored in an XML file in C:\ProgramData\JungleDisk. Removing the files in that location fixed the problem and I was able to re-enter the Amazon information and run the program without the service hanging.
Only four or five hours of work for what I guess was a gamma ray striking some part of my disk drive since there had been no configuration changes or installs to prompt this behavior.
We recently upgraded our main application to the latest version of the Infragistics controls. Everything converted, compiled, and ran fine. However, when you tried to open some forms in the Visual Studio designer, you got the message “The path is not of a legal form”. Looking at the project for these forms, they had invalid references to custom controls that used Infragistics controls. I deleted the references and added the newly compiled versions to eliminate the designer rendering error.
Since we do not remove the previous version of Infragistics the older controls are found at run time.
Recently we tried to build an older version of a system that is hosted on Windows 2003 server. Every project in the build would fail with Visual Studio unable to sign the DLL. Of course the DLL was not there in the target folder, but that was not the problem. The build had worked before we rebuilt the server.
A Google search produced a suggestion to change the file permissions on: >
C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys
We gave Administrators full access to the folders and were able to compile.
Just a couple of days earlier, I had to give IIS_WPG access to this folder in order for a web service to be able to read the keys and decrypt a WSE message. The service had worked fine after I had installed it and given access to the key file using the WSE key utility.
I noticed a pending Windows update icon was no longer in the system tray. It appears that update had tightened security on that folder.
A recent project I’ve been working on is a knowledge base with dynamic data structures. As such, all of the controls placed on the update page are dynamically created at runtime.
There is a drop down list for country and state, with the country list causing a post back to fill the state list. We needed the page to scroll back to the country list after postback to relieve the user of having to scroll down two pages.
It didn’t take much research to find the Page directive MaintainScrollPositionOnPostback=”true”. While this did get the page to scroll back to the drop down list, it also caused the page to scroll back to the submit button when there was a validation error (all done on the server side). Hey, no problem, I’ll just set that directive programatically only when the post back is caused by that drop down list.
I found a nice article by Peter Bromberg on a way to determine the control that causes a post back at http://www.eggheadcafe.com/articles/20050609.asp. I got null exceptions when trying to return the control, so I changed the code slightly to just return a string that describes the type of control.
But there is a scroll function, and by calling scroll(0, [saved y value]) I was able to finally get the page to scroll back only to the drop down list.
The post back control function, in App_Data/Global.asax.cs:
**The C# snippit placed in the Page OnInit function:**
<preclass="code"><spanstyle="color:green;">// hidden field to store scroll location </span><spanstyle="color:#2b91af;">Page</span>.ClientScript.RegisterHiddenField(<spanstyle="color:#a31515;">"__SCROLLLOC"</span>, <spanstyle="color:#a31515;">"0"</span>);
I was tasked with developing a web service for our development team that would mimick the operation of a client web service that has access limited by IP address. This target service was developed with WSE 2.0. The encryption used in WSE 2.0 is different from that in 3.0. Allthough some posts I read said you could change the encryption mode, I decided it would be less risky to adapt WSE 2.0 to ASP.NET 3.0.
There are lots of sample programs for using WSE 3.0 in ASP.Net 2.0, but none using WSE 2.0. Here are a couple of things that I had to change in the Web.Config given in the sample projects that come with the WSE install:
We were recently handed some mock up ASPX pages to use in a facelift of an existing ASP.Net 2.0 application. The pages used CSS extensively and unfortunately used no server controls as in the existing application. The conversion has been painful and time consuming.
Apparently label controls that have no text play havoc with the format, large blank areas will appear when you narrow the browser window. I had to change them to be not visible and add code to switch the visible attribute on and off. This rendered useless my long time use of an informational label with view state disabled, which never needed clearing or making not visible.
Also some controls such as the checkbox are rendered with a SPAN around them that causes unwanted wrapping problems. I tried to have the created SPAN’s inherit a style, but this would not fix wrap problems no matter how wide I made the span width.
It is interesting to note that checkbox controls that are dynamically added to a panel do not have this problem. Of course then you have to maintain the view state of the control yourself which adds a lot of complexity.