0

I'm using LoadFrom to call a remote assembly (DLL file is located on a server share). When I try to call any classes or methods from the assembly, however, VS2012 is telling me the namespace or type cannot be found. I would assume this is because the LoadFrom only executes at runtime.

Do I need to define each individual class within my code as needed, or will it all just magically work once I build the project?

Here's the snippet of code I'm working with - it's part of a larger click event on a form button. * Unfortunately I can't roll the remote DLL up into the app because it's an AutoCAD plugin and must be deployed as a single DLL file using local code only.*

        // Load SharePoint assembly file from server share
        Assembly SPAssembly;
        SPAssembly = Assembly.LoadFrom(@"\\server_name\spapps\ISAPI\Microsoft.SharePoint.dll");

// Specify web context & add user to group
       using(SPSite oSiteCollection = new SPSite("http://sub.companyweb.com"))
        {
            using(SPWeb oWebsite = oSiteCollection.OpenWeb("/subsite"))
            {
                using(SPWeb oWebsiteRoot = oSiteCollection.RootWeb)
                {
                    // Add new account to security group on app site
                    SPUser theUser = elevatedSite.RootWeb.EnsureUser("i:0#.f|extmembershipprovider|" + newUsername);
                    SPGroup theGroup = elevatedSite.RootWeb.Groups["SharePoint Group"];
                    theGroup.AddUser(theUser);
                    theGroup.Update();
                }
            }
        }

The problem I'm running into is that SPSite, SPWeb, and elevatedSite all return errors since they come from the SharePoint DLL. The overall code takes information entered into this form application, creates a SharePoint account in a SQL database, then adds the account to a group on the SharePoint site. The last part requires the SharePoint reference, and is the snippet I've shared.

Keep in mind that, while I'm using this in a SharePoint context, my question is NOT specific to SharePoint.

I need to know how to properly reference and use a remote assembly DLL file - one not located in the project folder, but at some centralized location that all users would have read access to.

Omegacron
  • 206
  • 3
  • 15
  • 3
    Why not just include a copy of the DLL in your project? – John Saunders Dec 19 '14 at 17:08
  • The app will not be deployed as an EXE but a single DLL file. Unfortunately, including it won't be an option. I realize it makes things needlessly difficult, but that's what I have to work with. – Omegacron Dec 19 '14 at 17:10
  • possible duplicate of [How to add folder to assembly search path at runtime in .NET?](http://stackoverflow.com/questions/1373100/how-to-add-folder-to-assembly-search-path-at-runtime-in-net) It looks like this might be your scenario. – Jeroen Mostert Dec 19 '14 at 17:20
  • I don't understand - why is it a problem that you will only deploy a DLL? – John Saunders Dec 19 '14 at 17:21
  • 1
    @JohnSaunders - it may just be that I don't know what I'm doing. I was under the impression that you couldn't build a project as a DLL file if it includes its own local DLL files (as opposed to just references). I take it from your confusion that isn't the case. Or do you mean embed it and then programmatically extract it? – Omegacron Dec 19 '14 at 18:05
  • I don't know what distinction you're making between "its own local DLL files" and "references". Try referencing the SharePoint dll, build your project, and you'll have a DLL that references the SharePoint DLL. The SharePoint DLL will need either to be in the GAC on the system it runs on, or in the DLL search path. – John Saunders Dec 19 '14 at 18:09
  • So since the GAC isn't an option, can I add the remote share location to the DLL search path? I thought assemblies had to be local to the solution or machine, but maybe I'm wrong. I'll do some further googling on that topic, it may be the answer i'm looking for. – Omegacron Dec 19 '14 at 18:23
  • @JohnSaunders - sorry for the terminology if it's wrong. By "local" files, I mean assemblies included with or embedded into the solution. By "references" I mean external assemblies that you're just pointing to (such as those included with .Net or Windows). – Omegacron Dec 19 '14 at 18:25
  • This is a distinction without a difference. There is only code (mostly source code) that gets built into the output DLL of your project, and other DLLs that are referenced. This includes .NET Framework code and your Microsoft.SharePoint dlls. Please just try it and see what happens, and see how it differs from your expectations. – John Saunders Dec 19 '14 at 18:32
  • Keep in mind that "solutions" and "projects" are things that are only relevant to Visual Studio. Once you've done a build, all there are is DLLs and EXEs. – John Saunders Dec 19 '14 at 18:33

0 Answers0