I have created a package with a bunch of assemblies that we will provide to our users. I want our users to be able to pick and add only references they need from within the package to a project. The user should be able to add this package at a solution level and then pick the references to be added to each project from the package added. Is this possible with NuGet?
Example:
MyPackage - contain foo.dll, bar.dll, bla.dll
User installs package "MyPackage" to solution
Project 1 - select and add reference foo.dll, bar.dll
Project 2 - select and add reference bla.dll
Currently, every reference of the package is added to every project. This is not the desired setup. I want only the selected references added. Is there a way to do this with Nuget?
NuGet is not designed to work this way. Packages are whole delivery units. Our recommendation in this scenario would be to package the individual assemblies according to how you want them individually installable.
Related
There are a few packages that I install 95% of the time I write any scripts in Linqpad. For instance, JSON.net, is a nuget package I install every single time, and RestSharp is a close second. So my question is, is there a way to set up Linqpad to install these nuget packages by default? If not, is there a way to add them to a collection so that they can easily be installed every time?
There are two ways:
Add these packages to the My Extensions query (then they'll be implicitly referenced by all queries)
Add these packages to any query, and press Set as default for new queries
Yet another option is via a code snippet. Right-click the editor and choose Create Code Snippet, then click the References checkbox to add the NuGet package. Whatever you name the snippet becomes a shortcut to add the package, so if you name the snippet json, you just type json followed by the tab key, and it will add the package.
I need to add a logic hook to a module built in Module Builder in SugarCRM 6.5( Community Edition ).
This logic hook should take all the fields that I have just saved after completing a form in a module and create a new record in a different module with these fields( in order to simulate a workflow ).
All the tutorials on the internet( on logic hooks ) talk about modifying stuff in "./custom/Extension/modules//..." but, after creating and deploying a module in sugarCRM, I do NOT have my module present in either "./custom/Extension/modules/" or "./custom/modules" .
Thank you for your time,
Those directories are for customizations and extensions like studio changes and custom code like hooks.
That those directories are not present only means that there are no customizations yet, so feel free to create those folders and add your hook inside.
Make sure that you create the directories with the correct names (as stated in the tutorials), including the correct case for all letters.
Also don't forget to give the web-process ownership/write-permissions to the all folders you create in custom, otherwise Sugar might fail to save studio changes and aggregation files at some point in the future.
When running kpm build against a project folder, the project.json metadata for the following fields is transferred to the output .nupkg file:
Version
Authors
Description
However, there does not seem to be a way to override the package ID or title (which defaults to the name of the containing folder).
Is this possible or is it necessary to produce a nuspec file through some other means in order to achieve this?
Sorry, it is not possible to specify a different name.
What's the scenario in which you need a different name?
I'm working with an application framework that has multiple products. It has a single installer and plugins are included/excluded based on build-server configuration.
I would like to change my build process so that multiple msi files are produced from a single build (one for each product, based on the framework). Is that possible ?
I was strugling the same problem.
I had 2 different builds from 1 wxs file, and for 4 configurations from 1 build. e.g. build=server\client,conf=debug\release,platf=x86\x64.
My issue: to cerate a solution with projects, numbered by the variable of build (in my case there was 2 projects, for server and for client separate). every project needs to be based on one wxs file, and build properties need to be different. I used the standard env variables on Configuration and Platform, and used my own variable Build. I've done in that way. If u need more biulds, create more projects, use more variables...
P.S. If u find the better way, plz contact me.
Using WiX 3.5, I have an MSI with instance transforms allowing me to install the software on the same machine with different product names. To do this, I have a "hard-coded" list of product id's and names in the .wxs file defined conditionally. However, I have only the single Feature-ComponentRef definition that includes both file and non-file resources.
Installation appears to work fine, but uninstalling the instances demonstrates the behaviour mentioned in these two sources:
http://msdn.microsoft.com/en-us/library/aa367797(v=VS.85).aspx
and
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Multiple-Instance-Transforms-Walkthrough-Proposed-Simple-Addition-to-WiX-to-Make-Them-Easier-td708828.html
Specifically, none of the non-file resources (in this case, registry entries) get uninstalled save the very last instance of my application. (i.e., if I uninstall in this order: instance1, instance2, and instance3 - only instance3's non-file resources are removed.
I am presuming this is related to not having unique GUID's for nonfile components (whereas this isn't an issue for file components)
So, I was wondering whether a valid approach would be to define a single .wxs file with one product id, name and one set of features, but have a custom bootstrapper generate new GUID's for the product and non-file components which then get inserted into the MSI database at runtime? i.e., Then when it comes time to uninstall or update, I would query the registry for installed instances and retrieve their GUIDs then.
This would permit instances to be created at runtime rather than hardcoded in the .wxs in advance, and to be uninstalled cleanly.
Does that make sense? Will Burn make everything better? :)
As of version v3.6.1511.0, there is now a "MultiInstance" attribute for components. This allows a guid to be generated on the fly for each instance as per Josh Rowes suggestion in his post to the WiX mailing list (see the link in the OP). I have tested and this works correctly to cause registry data to be removed when the current instance is uninstalled, and not when the LAST instance is uninstalled.
You don't need to have unique component ID's but you do need to have unique registry keys. Check out:
Authoring Multiple Instances with Instance Transforms
The article mentions:
To keep the nonfile data of each
instance isolated, the base package
should collect nonfile data into sets
of components for each instance. The
appropriate components should then be
installed based on conditional
statements that depend on the instance
identifier.
I actually don't know what they are talking about there. I created n-Tier multiple instance installers where all the files were isolated by unique INSTALLDIR ( type 51 custom action at runtime to mutate the destination based on the InstanceID ) and all the registry data was mutated using the InstanceID as part of the path as mentioned in the article. I supported up to Sixteen unique instances with unique configuration data and unique version #'s ( each instance could be serviced via major upgrade apart from the other instances. ) All of this was to support a SaaS deployment model for an nTier application and I never ever had to create components with unique GUIDS and/or Conditional expressions.
The only thing wonky I had to do was on the client side they wanted a Shortcut on the desktop. (The Client supported multiple instances also because a site might have v1.0 in Production and v1.1 in Test )
Because I couldn't mutate the folder name (fixed) and because MSI's ShortCut table doesn't support formattable, I had to write a custom action to author the ShortCut dynamically at install table using the InstanceID into a TEMP table and then MSI created the shortcut for me.