I have an application that does an FTP connection to an IBM mainframe and all has been working fine. I then recompiled against .NET 4 and the mainframe no longer accepts the file giving me an error message stating either the file doesn't exist, or I don't have permission for it.
This is what I use to send the file:
Ftp = (FtpWebRequest)FtpWebRequest.Create(FtpAddress + "%2F'" + "EM.MOM.FIMSDATA" + ".AA." + "RR(+1)" + "'");
Has Microsoft changed anything between .NET 3.5 and 4 because this points to a framework change?
I found this on Microsoft.
The cause of this issue is due to a behavior change in the
System.Net.FtpWebRequest class in .Net Framework 4. There has been a
change made to the System.Net.FtpWebRequest class from .Net Framework
3.5 to .Net Framework 4 to streamline the use of the CWD protocol commands. The new implementation of the System.Net.FtpWebRequest class
prevents the send of extra CWD commands before issuing the actual
command which the user requested and instead directly sends the
requested command. For fully RFC compliant FTP servers, this should
not be an issue, however for non-fully RFC compliant servers, you will
see these types of errors.
Solution is on:
http://support.microsoft.com/kb/2134299
Related
I am trying to connect to a remote ssh server using the SshNet package.
My code looks like this:
List<AuthenticationMethod> authenticationMethods = new List<AuthenticationMethod>();
authenticationMethods.Add(new PasswordAuthenticationMethod(SSHusername, SSHpassword));
SSHConnection = new SshClient(new ConnectionInfo(ip, Int32.Parse(SSHport), SSHusername, authenticationMethods.ToArray()));
SSHConnection.Connect();
When the program tries to make the connection, I get the following exception:
Exception thrown: 'Renci.SshNet.Common.SshConnectionException' in Renci.SshNet.dll
An exception of type 'Renci.SshNet.Common.SshConnectionException' occurred in Renci.SshNet.dll but
was not handled in user code
Server response does not contain SSH protocol identification.
I have been searching for a solution for 2 hours now, but haven't been able to fix it.
Looking through the source code of SshNet if found this error is thrown when the client doesn't get an ssh version from the server. I'm not an expert in this field, but looking at wireshark the server sends a packet with this info:
SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
I'm pretty sure this is the ssh version it's looking for. So I hope one of you guys can tell me what else I can try to fix this.
My Core project has target framework .NET standard 2.0, the UWP project's min version is Windows 10 1903. The SshNet package is on version 2016.1.0
I've tried several ways to make it work but there seems to be no easy way. Yes, there are a ton of plugins, configurations. But they do not work right as per Oct 2019.
OmniSharp-Vim client needs configuration, it covers only C# and it lists plugins integration that does not work anymore (try choosing it for linting in ALE).
YouCompeleteMe should work but it is large and seems bloated.
Deoplete don't have source for C# and configurations I found are out of date.
Coc.nvim does not even list C# and 'unofficial' configurations have issues (like this). Besides Coc.nvim seems to be an alien from VS Code.
LanguageClient-neovim I didn't find sensible configuration and it seems because C# LSP server needs .sln file.
So this seems that csharpers should go to VS (or Rider) and that is when MS proposed LSP. How do you make IDE like from nvim to work with C#?
Basically the client should start server like this and use LSP.
~/.cache/omnisharp-vim/omnisharp-roslyn/run -s <PATH TO SLN OR DIR>
I just got omnisharp / ale working successfully with a clean install. You may want to completely uninstall omnisharp (~\AppData\Local\omnisharp-vim or ~/.omnisharp) just in case you have old versions.
You didn't mention your OS; I have this working in both Windows 10 and Mac OS. If you're using Mac OS make sure you brew install libuv first.
My Environment
Windows 10 (v1903) and Mac OS 10.14.6
Vim 8.1.2244
dotnet core 3.1 - I'd expect 3.0 to work as well
Instructions
First off, I'm using vim-plug as my plugin manager to handle installation. I installed it in both Windows and Mac OS using the bash/powershell snippets in vim-plug's README.
Then I added the following to my vimrc (~\_vimrc on Windows, ~/.vimrc on Mac OS):
"vim-plug config
call plug#begin()
Plug 'OmniSharp/omnisharp-vim'
Plug 'dense-analysis/ale'
call plug#end()
" plugin config
let g:OmniSharp_server_stdio = 1
Restart vim, and run :PlugInstall. It will clone omnisharp and ale for you.
Next, find some C# solution, and ensure the solution builds at the commandline (e.g. dotnet build should complete without errors). You also need a SLN file if you don't already have one (dotnet new sln and then dotnet sln add MyProj.csproj)
Choose a C# file and open it in vim. You should see the following notification:
If the install doesn't autostart, you can start it with :OmniSharpInstall. The install takes a minute or two of downloading in a terminal window. After the installation is complete, reopen vim and execute :cd \path\to\my\solution to ensure the working directory inside vim is correct. Then open a file with e.g. :e MyProj\Program.cs.
The server will be started automatically; don't manually start it. I get a lot of syntax errors for the first few seconds while the server is starting, after that I don't have any errors.
To pull up the autocomplete, type something like Console. then hit Ctrl-x o:
The above screenshot has vim-airline for the bottom bar -- that's not part of omnisharp and isn't required.
The above screenshots are Windows, but it's also working fine in Mac OS:
My full vimrc is available here and the source code I'm testing with is available here.
So far here is my setting for this using Deoplete, OmniSharp and ALE (full config at https://github.com/artkpv/dotfiles/blob/master/.config/nvim/vimrc) :
" Install Deoplete and OmniSharp:
" - OmniSharp/omnisharp-vim " for LSP support (like start OmniSharp server) and code actions, etc
" - Shougo/deoplete.nvim " for better autocompletion
" - dense-analysis/ale " for highlights
function SetCSSettings()
" Use deoplete.
call deoplete#enable()
" Use smartcase.
call deoplete#custom#option('smart_case', v:true)
" Use OmniSharp-vim omnifunc
call deoplete#custom#source('omni', 'functions', { 'cs': 'OmniSharp#Complete' })
" Set how Deoplete filters omnifunc output.
call deoplete#custom#var('omni', 'input_patterns', {
\ 'cs': '[^. *\t]\.\w*',
\})
" ... then goes your mappings for :OmniSharp* functions, see its doc
endfunction
augroup csharp_commands
autocmd!
" Use smartcase.
" call deoplete#custom#option('smart_case', v:true)
autocmd FileType cs call SetCSSettings()
augroup END
I have a .Net console project referencing the Apache Ignite Nuget package. I'm interested in running the ignite-rest-http module within this same process. I'm using Apache Ignite 2.0.
I'm referring to the Apache Ignite REST Api as described here:
https://apacheignite.readme.io/docs/rest-api
I've tried the "Getting Started":
To enable HTTP connectivity, make sure that ignite-rest-http module is
in classpath. With binary distribution this means copying
libs\optional\ignite-rest-http to libs\ignite-rest-http.
However, it didn't seem to work. I started my process and went to http://localhost:8080, but there was no response.
Is it appropriate to host the ignite-rest-http module within a .Net process?
If so, is there something else I need to configure in order to host the ignite-rest-http module in a .Net process?
NuGet package includes a limited set of JARs required for core functionality. Optional libs are not included (NuGet.org has 30 MB package size limit).
To enable ignite-rest-http with NuGet:
Download full binary package from https://ignite.apache.org/download.cgi#binaries
Extract libs\optional\ignite-rest-http contents somewhere, say c:\ignite-rest-http
Provide IgniteConfiguration.JvmClasspath property with ;-separated paths to all http JAR files
var cfg = new IgniteConfiguration
{
JvmClasspath = Directory.GetFiles(#"c:\ignite-rest-http")
.Aggregate((x, y) => x + ";" + y)
};
Ignition.Start(cfg);
Console.WriteLine(new WebClient().DownloadString("http://localhost:8080/ignite?cmd=version"));
There are plans to include these JARs as a separate NuGet package: https://issues.apache.org/jira/browse/IGNITE-3275
I am moving a Classic ASP site from a Windows 2000 server to a Windows 2008 (both dev and prod). I have a .dll that was created in .NET 1.1. The error is occurring when function created in JScript located in this securityUtility.asp creates an ActiveXobject using the dll. The line looks as follows:
function getProfileFromLdap(user, pw){
var aClass, aProfile
aClass = new ActiveXObject("com.co.comp.security.ldap.LDAPLogin");
...
}
The error that is occurring is:
error '80070002'
E:\SITES\WWW-COMPANYSITE-COM\SITE\BINS../../siteInc/securityUtility.asp, line 850
I had run the following command to register the dll in the registry:
"C:\Windows\Microsoft.NET\Framework\v1.1.4322\RegAsm" coSecurity.dll /tlb:coSecurity.tlb
I don't know if it's worth mentioning but at one point the site worked perfectly in dev and erring when I attempted to move the site to production. I had moved the site to the new dev server (Windows 2008) so long ago. I had made notes so when I moved it up to production I knew what steps I had taken. I thought perhaps I forgot to record a step so in attempt to retrace what I did, I uninstalled the .dll and went through the steps I had recorded. It is now broken in dev but at one point it was working.
Another thing I'm not sure is worth mentioning is this site was the first site on the new dev server. .NET 1.1 was installed prior to any other framework. 4.0 and 2.0 were installed after the fact. On the prod server 4.0 was installed first and then 1.1. Not sure if that's signficant or not.
When the dev site was working I had confirmed the items were in the
registry comparing them to the old production and the new dev
servers and the new production
On the old production server there was nothing in the GAC
The coSecurity.dll is in the same file as the securityUtility.asp
(the page that the code belongs to).
The Application pool for the has "enable 32-bit applications" as true
for both of the new environments
"Everyone" is granted full rights on the .dll
I'm not sure what I'm missing!
This is what I ended up doing for those that have been beating their heads against the wall like I was:
opened a command prompt as administrator
navigated to where the dll was stored
unregistered the dll using
"C:\Windows\Microsoft.NET\Framework\v1.1.4322\RegAsm" /u
coSecurity.dll
re-registered the dll by using
"C:\Windows\Microsoft.NET\Framework\v1.1.4322\RegAsm" coSecurity.dll
/codebase
you'll get a regasm warning but should also get the message "Types
registered successfully"
After that I no longer recieved the error!
In general HRESULT 80070002 means "File Not Found".
My guess is you are missing a dependency. Try using Dependency Walker to see if there are any dependencies which should be included.
Also see this thread for some tips about registering COM servers manually.
I have an asp.net / C# web application running in a Windows environment.
The project builds fine and runs perfectly on my local machine's VB.net development server.
However, when I publish to the real application server I receive the following error message:
[OracleException (0x80004005): The provider is not compatible with the version of Oracle client]
[TypeInitializationException: The type initializer for 'Oracle.DataAccess.Client.OracleConnection' threw an exception.]
There is a version of this application currently up and running just fine, I am testing on the live server in a different directory. I even tried snagging the Oracle.DataAccess .dll from the working application but still get the same error message.
First off: The Oracle client/provider is a mess. And that goes for both the MS one (depreciated anyway) as well as the Oracle one.
In order to connect to an Oracle DB via the ODP.NET provider three things need to be setup properly:
Oracle client needs to be setup properly ( has nothing to do with the .NET provider, this referring to the installed oracle client usually in c:\oracle)
The ODP.NET provider needs to be compatible with the installed Oracle client
The architecture of client and provider and your application need to match, you cannot use the 64bit client with an x86 provider/application and vise versa
Usually the best is to have the newest version of both. But if you want to get rid of this issue once and for all use a third party oracle .NET provider.
UPDATE
One of the better ones is from DataDirect (no affiliation):
http://www.datadirect.com/products/net/net-for-oracle/index.html
It's not just installation (no oracle client necessary), but it's also faster, fully managed, x64 and general support is a way better than what you get with the ODP.NET one. It will cost you though.
The DevArt one is pretty decent as well (and much much cheaper):
http://www.devart.com/dotconnect/oracle/
We decided for the DataDirect for extensibility reasons, this should not be relevant to you however.
Here you can find a good compilation of third parties that build .NET providers, not limited to oracle though:
http://msdn.microsoft.com/en-us/data/dd363565
I came across the same scenario before
Reading this may help you some how ODAC Oracle for .NET
about your problem in your server you have to install the whole ODAC Client from oracle
the latest version now is 4.xx
i have installed it and everything works like charm
hope this helps :)
Take Care
I was able to solve this by searching for Oracle.DataAccess.dll on the prod server.
So instead of trying to build/deploy the project with the Oracle.DataAccess.dll from my development environment, I copied the .dll down from the prod server oracle client directory and included that as a reference instead. I also set the .dll properties "Copy Local = true" and "Specific Version" = true. So it looks like there is a mismatch between the oracle client version on my dev server and the prod server.
Equals, with Oracle.DataAccess.dll Works!!!!
//using Oracle.DataAccess.Client
object pdf = null;
var queryString =#"SELECT PDF FROM DIGITAL WHERE ID_DIGITAL=1001" ; //example
var ctx = new Entities();
var entityConn = ctx.Connection as EntityConnection;
if (entityConn != null)
{
var dbConn = entityConn.StoreConnection as OracleConnection;
dbConn.Open();
var cmd = new OracleCommand(queryString, dbConn);
using (var reader = cmd.ExecuteReader())
{
while (reader.Read())
{
pdf = reader[0];
}
}
dbConn.Close();
}
return pdf;
In addition to the other suggestions, just try running Visual Studio as administrator.
I spent a lot of time messing around with the GAC and various versions of the Oracle.DataAccess.dll, and in the end just running VS as administrator got it to run.