Japanese characters in host name for Chilkat FTP2 - c#

I went through Chilkat's forum where i see that forum is closed and I should post related question here on SO.
I am trying to connect to FTP server using FTP2 of chilkat, but it fails to connect to valid ftp server with valid credentials.
Host name does contain Japanese characters "w10jpnツ新".
My code looks like below:
Ftp2 objFtp = new Ftp2();
const string ChilkatFTPKey = ValidChilKatFTPKey;
bool success = objFtp.UnlockComponent(ChilkatFTPKey);
if (!success)
{
return;
}
objFtp.Hostname = _ftpServer;
Log.Write("Host Name Input: " + _ftpServer); //here I see "w10jpnツ新"
Log.Write("Host Name: " + objFtp.Hostname); //here I see "w10jpnツ新"
As you can see even after setting proper host name to objFtp.Hostname , that property is having garbage value and thus connection attempt fails.
How to fix it?
UPDATE
Initially this question was written to Chilkat technicians, but as now as there is no response from them, I m adding general tags to make it in reach of general people in Hope if they may know what can be possible reason behind such problem.
One thing i could think is if in setter of the property Hostname if they convert Japanese characters into something unwanted. But why would they do it.

I see the problem -- Chilkat is assuming that the Hostname is composed of Latin1 (us-ascii + accented European chars). I'll make the fix and I can provide a pre-release. Which version of the .NET Framework do you use, and which version of Visual Studio?

Also.. the objFtp.Hostname property should be set to a domain name or an IP address. The string "w10jpnツ新" is not a valid domain name. A domain name is something like "xyz.com" -- something that a DNS server can resolve to an IP address.

Related

Need an int to be empty (not 0) for FTP login in C#

I have a legacy C# program that gets files from an FTP site in a certain directory
string FeedFile = FTPOp.(
"ftp.XXXXXX.com",*NORMALLY PORT GOES IN HERE*, "USERNAME", "PASSWORD",
String.Format(" /Documents/Vendor/acknowledgements/{0}", FeedFile),
String.Format(RootDirectory + Name + "\\Input\\" + FeedFile)
);
I have set up several of these for different vendors without issue, but in this particular case there is no port number for the FTP site. It is blank. FeedFile format is Site(string), port(int), username(string), password(string), Directory we pick up from(string). (The lack of port is not an issue using our JSON routines, go figure)
If I leave the int space where the port number should be as blank,
Argument missing
If I try to put port: , argument missing
If I try to enclose the int space with double quotes, I am trying pass a string
where there should be an int and it errors.
If I remove that space, everything shifts back one space and Username is in the int spot and
password is in the Username spot and it errors twice.
Is there anything simple I can do here to pass null or empty parameter where the port (int) should be in C#?

Meaning of PingException "No such host is known"

I wrote a Windows Service which monitors devices on our LAN by (among other things) pinging them (using Ping.Send(); .NET 4.6.1). For a small number of PCs (3), I "occasionally" (once/day?) will get a PingException from Send(<ipaddr>, 5000), with InnerException.Message == "No such host is known". The next time the Send() is executed (~60 seconds later), it succeeds. I am using an IP address, as opposed to a name, so it's not a DNS issue.
I talked to the network admins about this issue, but they don't believe anything is wrong with the physical hardware. What other problems could this error be indicating?
Ping.Send() has various parameters which includes a parameter type of string than can either be a valid IP address or valid host-name. I suspect that your using one of the string parameters and sometimes passing an invalid IP (extra space, invalid IP etc...) and the Send() method conditionally resolves that you must be passing a host-name hence the exception regarding DNS.
Rather than send a string, why not utilize the parameter of type IPAddress as you've already stated that it should always be an IP. You can do this by attempting to parse the string into an IPAddress as shown below:
if (IPAddress.TryParse("**IP String**", out var ip))
{
using (var pong = new Ping())
{
pong.Send(ip);
//Etc...
}
}
Note that you will still need to fix your invalid data whichever way you look at it.

Directory.Exists(#"\\SERVERIP\aFolder\bFolder"); always returns false

The following path always returns false:
Directory.Exists(#"\\SERVERIP\aFolder\bFolder");
// where SERVERIP is the server-IP which is being accessed using Impersonation
After debugging the code, it places double-slashes in the Debugger.
I have accessed the above file path without the # and double-quotes in WindowsExplorer.
What am I doing wrong?
[ The code will run on a network ]
The problem might be in the paths-[Source/Destinations] (both or one of it[source/destination] might be causing the problem) due to the default-paths used by Visual-Studio. So let me explain how to check wether the paths are correct/incorrect step by step.
Configuring ** SOURCE-PATH **:
Some times this path DRIVE:\ProgramFiles\IISExpress (or some other path depending on the installation location of IIS) gets concatenated with the SOURCE-PATH you give in the input To solve this problem, follow/verify these steps:
Ensure that the SOURCE-PATH or File you are using is in the Project-Folder
To Access the SOURCE-PATH or File. Always use this path/way:
// 1. SOURCE-PATH + fileName with Extension<br>
Server.MapPath("~\FolderInsideProjectFolder\", "fileName.extension");
Configuring ** DESTINATION-PATH (to a Mapped-NETWORK) **:
This path creates a problem if the path you entered has some words mispelled OR if you don't have access to the specified Server-IP[DestinationServerIP]. To solve this problem, follow/verify these steps:
Before Accessing the DESTINATION-PATH or File , ensure that the IP-Address you are referring to is Accessible to the Account under which your Application-code is running.To learn how to run Applications under an Account. See Impersonization
To Access the DESTINATION-PATH or File. Always use this path/way:
// 2. DESTINATION-PATH + fileName with Extension
#"\\SERVERIP\aFolder\bFolder" + "fileName.extension";
NOTE:
Remember that the SOURCE-PATH can be checked if it (exists/does not exist) by addressing its Fully-Qualified-Address and in that case, it will return true if it exists (The full-path that windows-explorer shows you in the Address Bar (Windows-Explorer) like DRIVE:/....../
EXTRA-INFORMATION: (as it was the basic INTENSION)
One line instruction to Copy the file from local-system → networked-mapped drive/path is:
System.IO.File.Copy(
Server.MapPath("~\FolderInsideProjectFolder\", "fileName.extension"),
#"\\SERVERIP\aFolder\bFolder" + "fileName.extension"
[, true ] // Optional if you want the file to be over-written or not
);
Please inform, if any thing still is not cleared (but after some nice searching ☋ ☛ )
Many a times I have seen file (or directory) access problems when the user (a human, system user such as IIS_IUSR or an application) lacks required privileges.
According to this question where the asker is facing similar problem, I believe that this may help you.
Let us know, if it helps.

Remove domain name from machine name

Is there a safe way to remove the domain name from a machine name in C#?
Example:
MYMACHINE.mydomain.com
should be resolved to
MYMACHINE
Naive String Approach:
string fullName = "MYMACHINE.mydomain.com";
string resolvedMachineName = fullName.Split('.')[0];
If you want the 'basic' understanding of machine name, then use :
Environment.MachineName
It provides the machine name without the domain (traditionally the COMPUTERNAME variable at a command prompt). See: http://msdn.microsoft.com/en-us/library/system.environment.machinename.aspx
Edit #1
#Antineutrino - as I re-read my answer I realized we don't have enough information to give you a correct answer. When you say 'machine name', however, it is not clear if you want to know how to parse the string you have, or the proper way to retrieve what you want. If you simply want to know how to parse a string, the other answers are correct. On the other hand...
Do you want the NetBios name or Cluster Name? Then Environment.MachineName
Do you want the underlying name of a the machine running a cluster? You'll need to dig into the WMI classes.
Do you want the most specific name from all DNS strings that resolve to the current machine? i.e. web1 from web1.mysite.com? You'll need to resolve all the IP's bound to the machine.
If you go back and edit/revise your question with more details -- you'll get better/more-specific answers.
Edit #2
If I understand correctly, your scenario is as follows: You have similar code that runs on both client and server machines in a desktop environment. In all machines registries you've saved a DNS name for the server (server.myapp.com). Now in the code you want to determine if a machine is the server or not.
What You Asked For
string serverName = Registry.GetValue(REG_KEY, REG_VALUE, "key missing");
string currentMachine = Environment.MachineName;
if (currentMachine.ToLower() == serverName.ToLower().Split('.')[0] ) {
//do something fancy
};
Another Idea
Instead of shrinking the server name, you can grow the machine name.
string serverName = Registry.GetValue(REG_KEY, REG_VALUE, "key missing");
string currentMachine = Environment.MachineName +
Environment.GetEnvironmentVariable("USERDNSDOMAIN");
if (currentMachine.ToLower() == serverName.ToLower() ) {
//do something fancy
};
What you may want
Distributing registry keys seems a bit cumbersome. If it were me I would probably do one/some/many of the following:
Create different build configurations and use pre-processor directives to change the code. Something very roughly like: #if(RELEASE_SERVER) { /*do server code*/} #if(RELEASE_CLIENT) { /*do server code*/}
Use app.config ---that's what it's there to store configuration data. No need to pollute the registry. app.config can be transformed on build/deployment, or simply modified manually on the one server.
Store the majority of the configuration data in a central location. This way the app only need to know were to retrieve it's configuration from (even if that's itself).

ActiveDirectory error 0x8000500c when traversing properties

I got the following snippet (SomeName/SomeDomain contains real values in my code)
var entry = new DirectoryEntry("LDAP://CN=SomeName,OU=All Groups,dc=SomeDomain,dc=com");
foreach (object property in entry.Properties)
{
Console.WriteLine(property);
}
It prints OK for the first 21 properties, but then fail with:
COMException {"Unknown error (0x8000500c)"}
at System.DirectoryServices.PropertyValueCollection.PopulateList()
at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
at System.DirectoryServices.PropertyCollection.PropertyEnumerator.get_Entry()
at System.DirectoryServices.PropertyCollection.PropertyEnumerator.get_Current()
at ActiveDirectory.Tests.IntegrationTests.ObjectFactoryTests.TestMethod1() in MyTests.cs:line 22
Why? How can I prevent it?
Update
It's a custom attribute that fails.
I've tried to use entry.RefreshCache() and entry.RefreshCache(new[]{"theAttributeName"}) before enumerating the properties (which didn't help).
Update2
entry.InvokeGet("theAttributeName") works (and without RefreshCache).
Can someone explain why?
Update3
It works if I supply the FQDN to the item: LDAP://srv00014.ssab.com/CN=SomeName,xxxx
Bounty
I'm looking for an answer which addresses the following:
Why entry.Properties["customAttributeName"] fails with the mentioned exception
Why entry.InvokeGet("customAttributeName") works
The cause of the exception
How to get both working
If one wants to access a custom attribute from a machine that is not
part of the domain where the custom attribute resides (the credentials
of the logged in user don't matter) one needs to pass the fully
qualified name of the object is trying to access otherwise the schema
cache on the client machine is not properly refreshed, nevermind all
the schema.refresh() calls you make
Found here. This sounds like your problem, given the updates made to the question.
Using the Err.exe tool here
http://www.microsoft.com/download/en/details.aspx?id=985
It spits out:
for hex 0x8000500c / decimal -2147463156 :
E_ADS_CANT_CONVERT_DATATYPE adserr.h
The directory datatype cannot be converted to/from a native
DS datatype
1 matches found for "0x8000500c"
Googled "The directory datatype cannot be converted to/from a native" and found this KB:
http://support.microsoft.com/kb/907462
I have the same failure. I´m read and saw a lot of questions about the error 0x8000500c by listing attribute from a DirectoryEntry.
I could see, with the Process Monitor (Sysinternals), that my process has read a schema file. This schema file is saved under
C:\Users\xxxx\AppData\Local\Microsoft\Windows\SchCache\xyz.sch.
Remove this file and the program works fine :)
I just encountered the issue and mine was with a web application.
I had this bit of code which pulls the user out of windows authentication in IIS and pulls their info from AD.
using (var context = new PrincipalContext(ContextType.Domain))
{
var name = UserPrincipal.Current.DisplayName;
var principal = UserPrincipal.FindByIdentity(context, this.user.Identity.Name);
if (principal != null)
{
this.fullName = principal.GivenName + " " + principal.Surname;
}
else
{
this.fullName = string.Empty;
}
}
This worked fine in my tests, but when I published the website it would come up with this error on FindByIdentity call.
I fixed the issue by using correct user for the app-pool of the website. As soon as I fixed that, this started working.
I had the same problem with a custom attribute of a weird data type. I had a utility program that would extract the value, but some more structured code in a service that would not.
The utility was working directly with a SearchResult object, while the service was using a DirectoryEntry.
It distilled out to this.
SearchResult result;
result.Properties[customProp]; // might work for you
result.Properties[customProp][0]; // works for me. see below
using (DirectoryEntry entry = result.GetDirectoryEntry())
{
entry.Properties[customProp]; // fails
entry.InvokeGet(customProp); // fails as well for the weird data
}
My gut feel is that the SearchResult is a little less of an enforcer and returns back whatever it has.
When this is converted to a DirectoryEntry, this code munges the weird data type so that even InvokeGet fails.
My actual extraction code with the extra [0] looks like:
byte[] bytes = (byte[])((result.Properties[customProp][0]));
String customValue = System.Text.Encoding.UTF8.GetString(bytes);
I picked up the second line from another posting on the site.

Categories