I have created a basic MSI project using InstallShield2010. Now, I want the same project for building setup of different brands. Each brand have some information different from another like product name, guid etc.
Is it possible to that while building project I can provide a file path from where InstallShield can pick these parameters?
I think you want to utilize the InstallShield Automation Interface:
For advanced developers, InstallShield exposes a COM interface that
allows you to perform many of the same tasks from a program, such as a
Visual Basic executable, or a script, such as a VBScript file in
Windows Scripting Host. By calling methods, setting properties,
accessing collections, and so on, through the automation interface,
you can open a project and modify its features and component data in
many of the same ways that you would in the InstallShield interface.
With this "Automation Interface", you can write your build script to dynamically change the variables you're interested in (e.g. product name, guid, etc.) while building each version of your installer.
See: Automation Interface
Related
I am trying to do basically what it says in the title: I have created a class library (dll) using .NET 6.0 and I would like to add that as a reference in an Excel/Access VBA document. I diligently followed the steps here:
https://learn.microsoft.com/en-us/dotnet/core/native-interop/expose-components-to-com
No matter what I try, I cannot add the resulting dll as a reference in Excel. I just keep getting the message: 'Can't add reference to the specified file'.
A bit more info: I am able to create the Assembly.comhost.dll file, and I think I have done everything correctly, but no joy.
This is rather frustrating, as doing this in .NET Framework is but a click of a couple of checkboxes. In .NET Core (.NET 6) It seems to be a bit of a nightmare. Also, being able to create a tlb from the dll was always a perfect confirmation that you would be able to add your reference in Excel.
ANY help is most welcome!
Thanks!
in the tutorial you hav ementioned, ther is a topic "Register the COM host for COM". here a file named "ProjectName.comhost.dll" is used to register the assembly to the registry as a COM type library.
After doing this, i could the assembly in VBS with the fowing conde:
set projectObject = CreateObject("ProjectNamespace.ProjectClass")
newValue = projectObject.ComputeNewValue("abc")
Right now, I was not able to establish a reference to that type library in my Excel 2016, but the code sample works in VBA as well.
I could also in VBA
Set projectObject = CreateObject("COMServer.Server")
MsgBox projectObject.ComputePi()
with this repository : https://github.com/dotnet/samples/tree/main/core/extensions/COMServerDemo
But that works only with Registered COM not with RegFree COM (Go check README).
Not every component is a suitable candidate for use under Reg-Free COM. A component is not considered suitable if any of the following are true:
The component is an out-of-process (ActiveX EXE) server. Only DLLs
are supported.
The component is a system component or part of the operating system,
such as XML, Data Access, Internet Explorer, or DirectX® components.
For example, you should not attempt to isolate components such as
Microsoft XML (MSXml.dll) or Microsoft Internet Controls
(SHDocVw.dll). These components are either part of the operating
system, or can be installed with a separate redistributable package.
The component is part of an application, such as Microsoft Office.
For example, you should not attempt to isolate components such as the
Microsoft Word Object Model or Microsoft Excel Object Model. These
two components are part of Office and can only be used on a machine
that has the full Office product installed on it.
The component is intended for use as an add-in or a snap-in, such as
an Office add-in or a control in a Web browser. Such components
typically require some kind of registration scheme defined by the
hosting environment that is beyond the scope of the manifest itself.
The other problem is an arbitrary application may not be designed to
recognize isolated components, as it probably doesn't have a way to
reference your component through a manifest.
The component manages a shared physical or virtual system resource.
For example, it could manage some kind of data connection shared
between multiple applications or a device driver for a print spooler.
Source : https://social.msdn.microsoft.com/Forums/en-US/cc08575d-3506-4a0f-a9e2-f23c2162ad38/using-net-excel-addin-with-registrationfree-com?forum=innovateonoffice
But I couldn't find a way to add it in Excel as a reference.
Is there any way that I can create a template within forms to utilize for every user in the company?
For instance; let's say I have the Sales Order Screen (SO301000) and the Document Detail grid configured in certain way, that display different amount of columns than the default (either more or less columns).
For each user I want to use this template (and all the ones created) that I will apply when I add the new user.
I'l appreciate any guidance and help.
EDIT:
I provided answer for Form element ASP template below. Although reading your question again I think what you're trying to do would be more along the lines of automating grid column configuration. We call this feature Default Table Layout.
There's a feature request for it here:
https://feedback.acumatica.com/ideas/ACU-I-415
The feature has been shipped in version 2017R2 and is documented here:
https://help.acumatica.com/(W(1))/Main?ScreenId=ShowWiki&pageid=30f3229f-20f1-4055-9c03-e0fe3b37080d
Image copy of documentation page:
For ASP Form templates
There are two ways to work with customizations in Acumatica:
As a Customization Project, everything is done directly in Acumatica
instance through the web browser using the Customization Project Editor.
As an extension library (DLL file) compiled in Visual Studio which is then included in the FILES section of a Customization Project.
For method 1, I believe creating custom templates would be a bit of a hack and would not be officially supported, if someone knows otherwise please chime in.
For method 2, we ship the Visual Studio templates with the Acumatica Configuration Wizard (Acumatica ERP Installer).
Those templates are in the following folder:
My Documents\Visual Studio 20XX\Templates\ItemTemplates\Visual C#
The templates will be available for ASP.NET solution only. You can open Acumatica Instance Website as a solution if the website is already deployed:
When you open Add New Item dialog:
The Acumatica Templates will be available:
Those are standard Visual Studio templates so you can copy and re-use them to create your own. Microsoft documentation for creating user template applies and you can follow their guidelines. Note that working with Visual Studio and creating your own template is somewhat less user friendly than using Acumatica Customization Project Editor.
Acumatica T100 covers using Visual Studio to create customizations and would be a good starting point to learn the techniques involved:
https://openuni.acumatica.com/courses/development/t100-introduction-to-acumatica-framework/
I have an event handler feature that I've built for sharepoint 2007 and have deployed by moving the DLL to the GAC and creating Feature.xml and Elements.xml in the necessary folder and then installing them using the stsadm commands. I'm looking to avoid doing all this and instead have a WSP file that I can run to install the feature automatically in a production environment.
Thanks
Here's how I would proceed to convert your unmanaged items into a managed solution package in Visual Studio 2010:
Create an "Empty SharePoint Project".
Set the deployment target. In Solution Explorer, click the project node and look at the Properties pane. Set the Assembly Deployment Target property between GlobalAssemblyCache and WebApplication. In this case, we'd leave it as the default GlobalAssemblyCache.
Note also there's a handy property called Include Assembly In Package. This is used to exclude your default project assembly from the output package. Why do you need this? If your project contains no code: for example, you're just bundling up some third-party DLLs for deployment.
Replace your SharePoint DLL references. Follow the steps in Adam Macaulay's article to remove the v14 DLLs and add back the v12 DLLs.
Add an Event Receiver item. Right-click your project and point to Add > New Item... and select "Event Receiver". Give the event receiver a proper name and click Add.
Configure the Event Receiver. Visual Studio will connect to your (2010) SharePoint instance, then prompt you with a wizard to walk you through what events you want to handle and for which item types. The end result is an Event Receiver item in your solution with a stubbed-out class that overrides the proper methods, as well as an Elements.xml file that is configured appropriately. If you have both of these files already, you don't really need to complete the wizard "truthfully"... just select the first option, click Finish and let Visual Studio create the Event Receiver and corresponding Feature.
Add your code logic. In Solution Explorer, expand your Event Receiver node to reveal the .CS class and the corresponding Elements.xml. Copy the contents of your existing files into those locations.
Configure the package feature. In Solution Explorer, expand the "Features" node and locate the default feature (Feature1.feature). This was created when you added the Event Receiver item. For clarity's sake, rename the feature to something logical, then double-click it to open the feature in design mode. You should see your Event Receiver has already been added to the right-most pane ("Items in the Feature"). Were there others, you could selectively add/remove items from the feature. Here is the place you set the feature scope between Farm/Site/Web/WebApplication.
Also importantly, while in the Feature designer, notice the Properties pane has a wealth of additional options to set on the Feature. These can't be accessed any other place, so keep in the back of your mind that is where to find them.
Lastly, if you click the Manifest tab at the bottom of the designer, you can preview what the feature manifest will look like. The manifest can be manually edited if need be (effectively disabling the designer), but I have yet to find something I need to do that I can't configure via properties.
Configure the overall package. In Solution Explorer, expand the "Package" node and locate the default package (Package.package). Just as for features, double-click the package to open it in design mode. This is the same UI that features use, allowing you to pick which features will be part of this package. Your event receiver feature should already be added to the right-most pane ("Items in the Package").
Again, same as features, while you're in Package design mode, the Properties pane will make available certain properties that can't be edited elsewhere. Most notably, it is here you should clear the value out of SharePoint Product Version.
Also, we have the same manifest preview available to us via the Manifest tab at the bottom of the screen. This is handy for checking things like SafeControl entries (if you need them) and the like. The Assembly entry should reflect the correct deployment target (in this case GlobalAssemblyCache) that was set on the project.
Finally, the Advanced tab allows you to specify additional assemblies/SafeControl entries to the package, which is helpful if you're bundling up additional DLLs to the default project DLL.
Build your project. Obviously we want to make sure it compiles!
Test the deployment. When I test, I deploy to my 2010 instance first (because it's handy) and double-check that everything has been installed as I expected: DLL in the correct place (BIN/GAC), appropriate Web.config entries created, feature installed at the right scope, feature activates properly, etc.
Package the solution. Point to your Build > Package menu item. The WSP will be placed in the appropriate output folder for the active configuration. Test deploy to your SharePoint 2007 instance.
Check out "Build a SharePoint 2007 Web Part with a Visual Studio 2010 Visual Web Part Project" written by Adam Macaulay. I used this as a reference when I wanted to do the same, and the methodology works great. I've successfully converted a lot of our Visual Studio 2008 projects to 2010 projects, while maintaining compatibility with SharePoint 2007 environments.
I will make one suggestion: if you don't absolutely need the Visual Designer for your web part (i.e. your web part's output is made programmatically), then using the Visual Web Part template adds extra "junk" to your solution which I dislike.
Rather, in step 1 create instead an "Empty SharePoint Project", then right-click on your Project in the Solution Explorer and point to Add > New Item... and select "Web Part" (not "Visual Web Part"). You don't end up with the ASCX control and you can ignore the parts of Adam's tutorial that deal with updating the Register declarations.
This also has the added benefit of capturing the correct name for the web part files up front, so you don't have to rename a bunch of "VisualWebPart1xxx" files.
I'm new to SharePoint and trying to get my head around this. I have a simple Web Part project. I also have a custom Data layer project that uses the Microsoft Enterprise Library for data access. In the Web Part project, I am adding a reference to the Data layer project's assembly. I specified in the Package of the Web Part project that I want my Data layer's assembly to be deployed. I can verify this works by using standard ADO.NET classes and not the custom MS library. If I deploy to the SharePoint server (which I have 100% access to) using the Enterprise Library, I get the error message:
"Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Data"
What steps do I need to take to ensure this project and all future projects on the server can easily gain access to the Enterprise Library for data access?
Thanks!
You did everything correct until a certain point: Deployment.
When deploying external DLLs, which shall also be put into the GAC or somewhere else, you need to package them with the WSP aswell. This has become very easy with Visual Studio 2010:
Open your Package
Click on "Advanced" (on the bottom)
Add your external DLL and maybe even SafeControls for the web.config
with the push to leverage visual studio and dotnet with office based solutions, especially excel, where is the best article or information on how having office sheet with additional binaries and assemblies is sharable.
Do this external code get packaged with the spreadsheet
what if people start emailing the spreadsheet around. Is there any overhead of this additional assemblies. Is there risk of the binaries getting detached from the spreadsheet
It seems like microsoft has been pushing VSTO for over 5 years now but you read lots of mixed reviews and issues. Are we at the point where companies that do large VBA excel solutions can fully migrate over to dotnet without any real worries?
First of all, I want to answer your question on whether or not VSTO is ready for larger implementations. The answer is YES! Especially if the alternative is VBA. You have the entire .Net framework available, you can use web services, ADO.Net (better still, with the enterprise library). You can still write code that looks a lot like VBA, but is much more powerful. You can get more information by reading Walkthrough: Creating Your First Document-Level Customization for Excel. This page will give you an idea of what VSTO features are available to you.
Now, to answer your question on deployment.
It depends on whether you are making an Add-In or a document level customization. If its an Add-In, then you must install it on each client, and any passing around of documents will not effect that (Add-Ins are at the application level, and not at the individual document level).
I assume that you are talking about a document level customization, so I will center my answer around that.
When you create a document level customization, the assemblies are not loaded into the excel file (as they are with VBA). Instead, a document property is added telling the application that this document contains a manifest file (and tells it of the manifest file's location). The manifest file contains links to the assembly that makes up your customization.
As with any .Net application, there are sometimes other (referenced) assemblies that also need to be deployed. Not always are these assemblies in the GAC, so they would have to be located in the same folder as your executing assembly (in this case, your customization assembly). You don't necessarily have to place your assemblies in the same location as your excel file, though.
There are a few ways you can deploy the customization.
You can store all of the assemblies and the excel file in a folder and run the application that way (if the excel file is passed around, the users must pass around the entire folder).
You can run an setup program that installs the assemblies to a specific folder on the users computer, and specifies the manifest at that location (if the excel file is passed around, the users must also pass around the setup program).
You can install the assemblies in a network location and specify in the document properties, that the manifest and the assemblies are all at that network location (if the excel file is passed around, nothing needs to be passed along with it - but there are security settings that need to be made. Read this page for more information).
Any way that you decide to do this, here is the page you need to read in order to understand the document properties that enable the customization.
You need to make sure all of your users have the prerequisites installed. The easiest way to do this is to give them all a setup program. If you create a setup project for your customization, you can setup the bootstrapper to automatically install the prerequisites. You can also do this if you use ClickOnce to install the customization. This page will give you all the information you need to know regarding deployment.
Here are some other helpful links you will need to see:
Application Manifests for Office Solutions (2007 System)
Deployment Manifests for Office Solutions (2007 System)
Application and Deployment Manifests in Office Solutions
I hope this helps. Once you read all of this information, I think you'll agree that VSTO is a much better choice than VBA. You just have to plan your deployment carefully.
I created a Excel add-on and deployed it to a server. Then I passed around two links, the setup.exe file and the link to the actual Workbook. The workbook file never changed - it's purpose was to open and load the add-on which was now in the user's Add/Remove Programs. The add-on itself would check for updates on startup.
So if they start emailing the workbook around, great! I believe in theory, the workbook would download the add-on if it was missing, but I don't have a fresh computer around to test that. If it doesn't, it's just a simply exe to install (which will update on launch anyhow, so outdated isn't an issue).
For document-level deployment, I recommend the following three links:
https://msdn.microsoft.com/en-us/library/ms268758(v=vs.90).aspx
https://msdn.microsoft.com/en-us/library/ff937654.aspx
How do you assign the Assembly Location of an Excel VSTO Installation?
Unlike application-level solution, document-level has 2 special properties: _AssemblyLocation and_AssemblyName, which indicate the *.vsto position. To set these properties by install path, a custom action project should be created to record the target path when installing, and packaged together with setup.exe. Then you could put your excel file anywhere (on local machine) and open it in the correct way.