If there are more plugin classes in one Visual Studio assembly, do we have to make one signing (.snk file) for each class, or it is enough to make one signing for the whole assembly?
Also, is there any difference if i create .snk file before creating a plugin class or not?
It's a single key for each assembly. Keys can be shared between assemblies.
And no, your key can be created before your assembly is.
Related
I have a plugin assembly I have registered to D365 CDS(cloud) and it runs fine.
I want to reference and use some classes in a separate project included in my solution in Visual Studio.
Adding the project as a reference will give File Not Found exceptions. I am able to add the individual classes using the Add Existing Item - Add Link option, but I would like to do it as a whole project reference instead of individual links. Is that possible without using ILMerge and how would I accomplish that?
As I mentioned in my comment, I create a SharedProject in Visual Studio (2017). I put all my Business Logic into this Project (or Projects).
Then I can have a "Workflow" and a "UnitTest" project that each refer to that Shared Project.
More Info
i have implemented successfully custom actions in my visual studio setup project to encrypt app.config file and also to capture user input through textboxes. However my project has 3rd party dll references which I want to merge. I have done merging using redgate smart assembly and after that when I build the setup project using the merged obfuscated assembly there is an error during installation( unable to get installer type for assembly error 1001).
Can you show me how to encrypt app.config and capture user input via custom dialog using Installshield
InstallerClass Custom Actions ( InstallUtil ) are very fragile and should never be used. The problem you are having is most likely that your custom action assembly has a reference to an assembly that can no longer be found on the disk since it's been merged into another assembly.
This problem would happen with InstallUtil CA's whether it's being called by a Visual Studio Setup Project or an InstallShield Basic MSI project because the problem isn't in MSI, it's in your CA.
I would reccomend you look at WiX Deployment Tools Framework (DTF). It's a far cleaner way of implementing managed code custom actions so that the CA and all of it's dependencies appears as a single native DLL to the Windows Installer. At runtime the native stub extracts all the files, runs your .NET code and marshals all of the MSI API calls between the two sides for you.
It's very clean and it can be used in Setup Projects, WiX, InstallShield and other MSI authoring tools because the output is a simple Win32 DLL with exported stdcall functions. ( Msi Type 1 Custom Action Spec )
I have created an extension for VS 2010 that deploys a project template. The project template uses a custom wizard (in a specific assembly) that is called when I create a new project based on this template.
I want to package the assembly containing the wizard within the VSIX, so that it gets deployed somewhere the template can find it (I know GAC is not an option with VSIX).
Basically if I deploy the assembly to the GAC, install the VSIX and then create the project the wizard is invoked successfully.
If I do the same without deploying the assembly first, the project templates does not find the assembly when I create the project.
My question is: how to deploy a project template and the assembly it needs using a VSIX package?
Thank you for your help
EDIT: I changed the VSIX Sub Path of the wizard assembly reference to "ProjectTemplates" in both the installer project and updated the vsixmanifest content assembly reference accordingly. It seems to work now.
You don't need to get your assembly containing the IWizard implementation in the GAC. You can simply declare it in your extension.vsixmanifest file as an Assembly element in the Content section.
Unfortunately, this doesn't appear to be documented well anywhere.
The only tricky part is making sure that the AssemblyName attribute has the correct value.
I had no luck with the Assembly element technique to work, so in case anyone else runs into the same problem, here's another solution.
Visual Studio looks for wizard DLLs using the BindingPaths registry key. If you add the folder containing your DLL in a subkey of BindingPaths, then Visual Studio will find your DLL.
To do this from a VSIX, create a .pkgdef file in your VSIX project. Set its Include in VSIX property to True, and paste the following text into it:
[$RootKey$\BindingPaths\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}]
"$PackageFolder$"=""
(where the Xs represent the package GUID, though I suspect any GUID will do).
This works for me:
[$RootKey$\BindingPaths\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}]
"$PackageFolder$"=""
But assembly element doesn't work.
I have installed the strong named assembly TestReflection into the GAC (I am using .NET 4.0 and VS 2010).
Different versions of the TestReflection DLL are in GAC of .NET 4.0 (C:\WINDOWS\Microsoft.NET\assembly\GAC_32\TestReflection\), however, the assembly does not appear in the "Project" -> "Add reference" box of VS 2010.
How can I refer to my assembly deployed in GAC at design time from another project?
This page says that:
You cannot add references from the Global Assembly Cache (GAC), as it is strictly part of the run-time environment.
Referring to this statement, I would like to know how to make your project's DLL shared assembly for other consumers if it's the requirement?
The dll's shown in the .Net tab of the "Add references" dialog are not actually the ones registered in the GAC. They are found by searching a few paths on your filesystem.
The paths being searched are located by Visual Studio by looking up the following registry entries:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NetFramework\{Version}\AssemblyFoldersEx\
There should be some keys added there already, so if you want your own dll to show up on the .Net tab, you can add it to one of the folders defined there. You could also add a new registry key pointing to a custom folder, which would only contain your own dll's.
The GAC is only meant for loading assemblies at runtime after your application has been deployed, so I don't think you should use it while developing. When you deploy your app, make sure to set "Copy local" to false on your reference so the dll won't be copied to the bin folder, and then install it into the GAC and it will be loaded from there instead.
Another simple option would be to manually edit the project file as XML in visual studio (You will have to unload the project first), and simply add node <Reference Include="<name of dll>" /> in MSBuild project file. After reloading the project, VS will pick up the reference without problem.
If you want to add Global Assembly Cache references to your VS2010 project, there is an extension you can use: Muse.VSExtensions.
It has some quirks but does a decent job. Check it out...
The answer is the Reference Paths in the property windows, you have to set it with the GAC path
Please see my post here:
Specifically, I am using Wise Installation Studio to install several shared .NET 2.0 assemblies into the GAC. These are being used by some legacy COM application files as well as other application assemblies.
I have the flag for "Generate COM interop registry keys for .NET assembly" set.
Reference counting appears to be working for removing the actual assembly from the GAC, but the COM registration information is getting removed with the first uninstall via ARP.
I am wondering if there is some work around for this, if I would be better off installing the assembly to Common Files, or if there are any other suggestions out there?
How I could read on the http://www.ssw.com.au/ssw/standards/wisesetup/WiseStandards.aspx page using of "Generate COM interop registry keys for .NET assembly" allow you just add a set of registry keys to MSI. As in all Windows Installer Setups it is important to define to which MSI component a registry key or a file belong. If you make these registry keys as a part of the same components as the file and the assembly, the keys will be removed always together with the assembly. If multiple setups use the same component GUID, then only if you uninstall the last setup used the component, the component will be uninstalled.