Post a reply

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

moonhead

Was there any resolution to this? I'm porting my console application to a UWP application and have run into the same issue.
martin

OK, I agree that the IReflect may not be enabled in the UWP.
But that does not mean that IReflect was removed from .NET framework entirely, nor that it is supports on Windows Phone only.

The IReflect is still a part of the full .NET framework even on the latest versions and even on the PCs. And I doubt it will ever be removed.

While the IReflect is not really needed to run WinSCP .NET assembly, I'm not sure if you would be able to use the assembly in UWP project anyway. I'll test this.
Peter R

My line of reasoning seems quite straightforward: the link in my previous post refers to a limitation that IReflect is only supported for Windows Phone 8.1 or earlier.

But it appears that it isn’t really a version thing (or not only a version thing). The issue is that as I’m working for UWP, Visual Studio has sneakily added a subset of the core .NET functionality to my project instead of a full set for a specific .NET-version. Depending on what type of project I create for the WinSCP.NET calls, it adds one of the following .NET collections:
.NET for Windows Store Apps https://learn.microsoft.com/en-us/previous-versions/windows/apps/br230302(v=vs.140)
.NET Portable subset https://learn.microsoft.com/en-us/previous-versions/dotnet/framework/cross-platform/portable-class-library

Both of which don’t include IReflect:
https://learn.microsoft.com/en-us/dotnet/api/system.reflection

The documentation of this is messy, and the least inconvenient way to detect it is after creating a project in Visual Studio, then the Object Browser gives a view on all possible component directories. All mentioned ‘standard’ .NET libraries, up to 4.6.1, contain IReflect, the subsets mentioned above don’t.

As I’m sure my applications will only run on PCs, in fact the whole portable thing doesn’t matter for me, I could just as well handle a ‘non-portable’ .NET collection, but UWP was chosen for my project from the beginning and I’ve not yet found a way to load the standard .NET libraries to it. It might not be possible at all. In that case, I’ll probably not be able to use WinSCP either.
martin

Re: Is WinSCP.NET only supported for Windows Phone?

and that the most recent docs refer to a version limitation, suggests that IReflect has been removed from the most recent versions of the .NET namespace.

Where do you see that suggestion?
Guest

Re: Is WinSCP.NET only supported for Windows Phone?

martin wrote:

I do not see any support for your claim that IReflect is for Windows Phone only. Of course it's not.

But on the contrary, it's probably not supported on UWP.


Sorry, not only is there version confusion about the IReflect interface, even there is a version conflict in the docs about it, in which I got lost. I should have used the most recent url for it:
https://learn.microsoft.com/en-us/previous-versions/windows/apps/bctfs8we(v=vs.105)

Which tells at the bottom:
Version Information
Windows Phone OS
Supported in: 8.1, 8.0, 7.1, 7.0
Platforms
Windows Phone

The 'System.Reflection' namespace is part of .NET, while the namespaces for the UWP API start with 'Windows'. What I did is creating a separate project inside an UWP-solution that refers to the System.* namespace. That is basically allowed (and otherwise Visual Studio would have complained about other references to this namespace).

That it actually does complain about IReflect, and that the most recent docs refer to a version limitation, suggests that IReflect has been removed from the most recent versions of the .NET namespace. When you look at the url above, then toggle the document-version at the top of the page, you can go to earlier versions of the docs that get earlier versions which do not show this limitation, probably because they still contained it.

But so far, I could not get it working by choosing other OS-targets in my project.

Summarizing: as far as I can see the WinSCP.NET assembly is no longer supported in the most recent Windows-APIs, so others might get problems as well.

But admittedly, as said, my knowledge of .NET is limited, so I may be wrong.
martin

Re: Is WinSCP.NET only supported for Windows Phone?

I do not see any support for your claim that IReflect is for Windows Phone only. Of course it's not.

But on the contrary, it's probably not supported on UWP.
Peter R

Is WinSCP.NET only supported for Windows Phone?

Hi,

I'm working on a Universal Windows Platform app that should do both uploads and downloads to external servers. It should run in a background thread. It should run on Windows 10 PCs, but as I don't yet have the right development machine, I'm doing the initial work on Windows 8, using Visual Studio 2015.

As options available for FTP-uploads in the standard Windows API are limited, I considered calling the WinSCP.NET assembly.

My solution contains, among others, two projects
1. My normal Javascript project for Windows 8
2. A separate C# project just meant as the interface to WinSCP.NET. I tried two versions, one for Windows 8, one for Universal Windows. This project contains:
2a. The WinSCP.NET assembly v5.9.2, as loaded by the NuGet package manager
2b. Currently a single C# class which is currently not much more than a copy of the example in the docs:

using System;

using WinSCP;

namespace WinSCPComponent
{

    sealed public class Example
    {
        public static int Main()
        {
            try
            {
                // Setup session options
                SessionOptions sessionOptions = new SessionOptions
                {
                    Protocol = Protocol.Sftp,
                    HostName = "example.com",
                    UserName = "user",
                    Password = "mypassword",
                    SshHostKeyFingerprint = "ssh-rsa 2048 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx"
                };
           
                using (Session session = new Session())
                {
                    // Connect
                    session.Open(sessionOptions);

                    // Upload files
                    TransferOptions transferOptions = new TransferOptions();
                    transferOptions.TransferMode = TransferMode.Binary;

                    TransferOperationResult transferResult;
                    transferResult = session.PutFiles(@"d:\toupload\*", "/home/user/", false, transferOptions);

                    // Throw on any error
                    transferResult.Check();

                    // Print results
                    foreach (TransferEventArgs transfer in transferResult.Transfers)
                    {
                        //Console.WriteLine("Upload of {0} succeeded", transfer.FileName);
                    }
                }
                return 0;
            }
            catch (Exception e)
            {
                //Console.WriteLine("Error: {0}", e);
                return 1;
            }
        }
    }
}


However this setup fails immediately because I get a compilation error at the field WinSCP.Session: "Reference to type IReflect claims it is defined in 'mscorlib', but it could not be found."

Indeed this interface is not defined in the associated Windows-classes, and checking this in the Windows API (https://learn.microsoft.com/en-us/dotnet/api/system.reflection.ireflect) tells me that it is only supported for Windows Phone.

Obviously, this is quite fundamental, so it looks like this approach isn't an option in my case, and hacking the source of the WinSCP.NET assembly isn't a valid option as well as my experience with C# is almost zero. WinSCP.NET is the only reason I started using it.

But to me it seems strange that you can use the tool for a phone but not on a PC, so I before I continue my search for alternatives I want to make sure that I'm not missing something.