I have a SharePoint 3.0 server.
Today I changed the domain user password.
I am logging in from a WORKGROUP (i.e., non domain) computer.
Then it gives error 500 and does not proceed to give me a login prompt to supply the new password! Now there is no way to log in.
Ironically, if I test this with Firefox 2.0 I can get the login prompt!
So here is the fix.
It is breaking because your IE is sending an incorrect credentials to SharePoint 3.0, and the reason is because the server is (most likely) in your Internet and the IE, knowing the trusted site, it sends out incorrect credentials. When this happens though, it is crashing the SharePoint 3.0.
To get around this issue, change the Security level of the SharePoint 3.0 server to the default Internet level, then the login prompt should show up.
Thursday, April 19, 2007
Friday, April 06, 2007
Java Technology? Why people still bother with it?
Another frustrating part of day with figuring out why Java app does not work on my computer at work.
Please do know that I use Mac most of the time for my own use so this is not really me just talking from the Windows standpoint.
But my Java experience has been nothing but trouble, and there has hardly been any time when a Java technology based stuff worked well. I really feel that the technology is flawed, and wish it had not but here are some examples.
A year or a bit more ago, I was involved in a deployment of a time card system for a company I used to work for. The UI part of this application was implemented in Java. While it is not entirely the Java's fault, this specific deployment was based on an older Java platform, and it only ran on a specific version of the Java implementation. If you happened to install any different (i.e., later) version of it, that time card application stopped to work. A significant my own time was wasted to go through bunch of users who has compromised the Java version by "mistakenly" installing newer Java. It seemed to me that the Java lacked any backward-compatibility architecture, for example, running different versions side-by-side.
Later on in another company we bought an advanced firewall appliance and it came with a Java based "friendly" GUI software. I was excited to know that "Great, I can use this both on my Mac and PC." So I load this on my Mac and it says, "This program only run best on Windows." In fact it actually runs on Mac, but it does not work very well at all. They were not kidding.
But then what occurs to these people who develop this kind of tool to write something on Java but then make it only runs on Windows? In my opinion, I don't think it is really the developer's fault. The supporting Java platform should have been designed so that it would work on all latest Java supported platforms. I think that Java failed us again.
Today, I was playing with a remote management (i.e., remote screen) capability on a certain Windows server we bought. I was testing this on Windows. And what happens? The entire Java environment freezes up.
I am hoping that there will either be a significant improvement in Java, or hope someone would come up with the cross-platform environment that works on just about any.
The about the only thing that comes close to it seems to be the Flash. I cannot ever recall I had ANY time that a You Tube video did not play on all sorts of browsers both on my Mac and Windows. It seems to deal with visioning issues and such and it never gets in my way like Java does.
Please do know that I use Mac most of the time for my own use so this is not really me just talking from the Windows standpoint.
But my Java experience has been nothing but trouble, and there has hardly been any time when a Java technology based stuff worked well. I really feel that the technology is flawed, and wish it had not but here are some examples.
A year or a bit more ago, I was involved in a deployment of a time card system for a company I used to work for. The UI part of this application was implemented in Java. While it is not entirely the Java's fault, this specific deployment was based on an older Java platform, and it only ran on a specific version of the Java implementation. If you happened to install any different (i.e., later) version of it, that time card application stopped to work. A significant my own time was wasted to go through bunch of users who has compromised the Java version by "mistakenly" installing newer Java. It seemed to me that the Java lacked any backward-compatibility architecture, for example, running different versions side-by-side.
Later on in another company we bought an advanced firewall appliance and it came with a Java based "friendly" GUI software. I was excited to know that "Great, I can use this both on my Mac and PC." So I load this on my Mac and it says, "This program only run best on Windows." In fact it actually runs on Mac, but it does not work very well at all. They were not kidding.
But then what occurs to these people who develop this kind of tool to write something on Java but then make it only runs on Windows? In my opinion, I don't think it is really the developer's fault. The supporting Java platform should have been designed so that it would work on all latest Java supported platforms. I think that Java failed us again.
Today, I was playing with a remote management (i.e., remote screen) capability on a certain Windows server we bought. I was testing this on Windows. And what happens? The entire Java environment freezes up.
I am hoping that there will either be a significant improvement in Java, or hope someone would come up with the cross-platform environment that works on just about any.
The about the only thing that comes close to it seems to be the Flash. I cannot ever recall I had ANY time that a You Tube video did not play on all sorts of browsers both on my Mac and Windows. It seems to deal with visioning issues and such and it never gets in my way like Java does.
Wednesday, April 04, 2007
Calling Unmanaged C++ from C#. DLL Won't Register?
I just wasted about 2-3 hours of my time because my assumption was wrong, and as it turns out that this problem is fairly common, but nobody cannot quite explain it.
I had to write a DLL so that you can call it from C#. There still are some things that is easier done in C++, especially when it comes to dealing with the drivers and I/O directly. Or you simply have someone else's DLL or Win32 DLL etc. you need to call from your C# (VB.NET).
The Problem,
You think you should add the DLL as a Reference in the same manner as other C# assemblies. So you do that then the system complains
A reference to "C\blah\blah\blah\younameit.DLL" could not be accessible. Please make sure that the file is accessible, a valid assemply or COM component.
The Bad Assumption
I thought that I add the reference to any DLLs that I access in my C# project.
The Correct Way
It is not necessary to reference the DLL. That reference is made in your Plaforom Invoke code. If this had not made sense, you should read up on System.Runtime.InteropServices
I had to write a DLL so that you can call it from C#. There still are some things that is easier done in C++, especially when it comes to dealing with the drivers and I/O directly. Or you simply have someone else's DLL or Win32 DLL etc. you need to call from your C# (VB.NET).
The Problem,
You think you should add the DLL as a Reference in the same manner as other C# assemblies. So you do that then the system complains
A reference to "C\blah\blah\blah\younameit.DLL" could not be accessible. Please make sure that the file is accessible, a valid assemply or COM component.
The Bad Assumption
I thought that I add the reference to any DLLs that I access in my C# project.
The Correct Way
It is not necessary to reference the DLL. That reference is made in your Plaforom Invoke code. If this had not made sense, you should read up on System.Runtime.InteropServices
Subscribe to:
Posts (Atom)