How to find a class in a list of Nuget packages - nuget

My team is using more and more NuGet packages as a way to break the system into smaller pieces and share things between parts. We have adopted a sort of SRP principle for packaging, creating small and hopefully cohesive packages that do just one thing (logging, auditing, security stuff, etc).
Ideally they should be so cohesive and self-contained that it would be straightforward to know what package will contain what you need. However we are not yet there and sometimes is difficult to know what package you should add to access some functionality.
My question is: is there any way to publish and navigate package content information? Like, for instance, in MSDN you can see what assembly contains a class. Would it be possible to know something like that, at the package level?
Thanks.


It's a very localised version, but there is a package searcher for the ASP.NET 5 packages hosted on NuGet. It might be possible to host a version that looks at a wider scope at some point.
https://packagesearch.azurewebsites.net/


The closest functionality I can think of is implemented in ReSharper. However it can only search the packages in nuget.org(closed issue on GitHub). Since packages don't expose type info, JetBrains built a custom index and that's the only data source it can query.

Related

What is the difference between package and project in Eclipse?

I don't really understand what the point of having a package is. Every Class is kept in a different file, so what's the point of using different packages in a single project?

An Eclipse project has nothing to do with Java. It is a feature of Eclipse to organize and configure your different projects.
A Java package is a language feature of Java. You can use them to structure your project and control visibility between different classes. This becomes necessary even in relatively small projects, which already might have a few hundred classes. I suggest you look for a basic tutorial on what a Java package is and what it can do. To give you a headstart, here is what the official documentation has to say about the purpose of bundling related classes in a package:
You should bundle these classes and the interface in a package for several reasons, including the following:
You and other programmers can easily determine that these types are related.
You and other programmers know where to find types that can provide graphics-related functions.
The names of your types won't conflict with the type names in other packages because the package creates a new namespace.
You can allow types within the package to have unrestricted access to one another yet still restrict access for types outside the package.

Packages are useful for many things. For example, you could store a set of files that do a given task TASK in a package named task.
Packages are a way for developers to find easily and quickly a file, knowing what the role of the file is.
Whenever your project starts growing, packages are essential.
See this lesson for basic understanding of packages utility.

Is there a website where I can view XML documentation for NuGet packages?

I have published a couple of NuGet packages (.NET class libraries). The packages include XML documentation file for each DLL. All packages are published on www.nuget.org and www.symbolsource.org.
Now, is there a website/service which will automatically generate (and host) documentation for my packages? I am picturing some sort of mini-site for my packages, where users can see all class definitions, their methods and related documentation from the XML file (basically something like MSDN but for my package)?
Ideally every time I publish a nuget package, I want to be able to go to www.SomeNugetDocumentationSite.com/packages/MyPackage and see MSDN-like documentation for my packages.
Thank you.

I have noticed that nudoq.org does such thing for my Pkcs11Interop package. I have never registered there or anything like that so I guess they are generating documentation from XML file which is present in the package.
However I still prefer to generate documentation with doxygen (which by the way uses the same inlined XML comments present in C# source code) and host it by myself because this way I can fully control the result.

building NuGet package; want to add content to disk, but not solution

I am building a NuGet package. I want to add content that will be written to disk, but not added to the project. I've looked at many websites and the available documentation, but nothing is jumping out at me.
I suspect I could achieve this in a round about scripting way, but would prefer a simpler solution.

Is there a way to create just ONE NuGet package that will target multiple project types (web forms, MVC, etc.)?

My company commonly uses Web Forms projects and MVC projects within Visual Studio. When creating a package, the package will/should be different for the different project types.
QUESTION: Rather than creating two slightly different NuGet packages that do exactly the same thing for the two different project types, is there a way to just create ONE NuGet package that's project-type independent? So when installing the package, there will be logic in, perhaps, the .nuspec file that will say "if the project this is being installed on is Web Forms, then do this. If it's MVC, then do this".
I've looked at the following link, for the different ProjectProperties on a project - this seems like something I would utilize, but I'm not sure how.

I would not create a single package for different platforms, because you're loosing flexibility. You might want to take a look at how the Glimpse guys have created their packages as they were facing the same issue.
Check the following packages and the way they are chained:
http://www.nuget.org/packages/Glimpse/
http://www.nuget.org/packages/Glimpse.Mvc4/
http://www.nuget.org/packages/Glimpse.AspNet/

Salesforce - How to Deploy between Environments (Sandboxes, Live etc)

We're looking into setting up a proper deployment process.
From what I've read there seems to be 4 methods of doing this.
Copy & Paste -- We don't want to do this
Using the "Package" mechanism built into the Salesforce Web Interface
Eclipse Force IDE "Deploy to Server" option
Ant Script (haven't tried this one yet)
Does anyone have advice on the limitation of the various methods .
Can you include everything in a Web Interface package?
We're looking to deploy the following items:
Apex Classes
Apex Triggers
WorkFlows
Email Templates
MailMerge Templates -- Can't seem to find these in Eclipse
Custom Fields
Page Layout
RecordTypes (can't seem to find these in Website or Eclipse)
PickList items?
SControls

I recommend the Force.com Migration Tool.
For reference:
Force.com Migration Tool Documentation
Migration Tool Guide
The Migration Tool allows you to use ant targets to move your metadata between salesforce.com organzations.

I can speak to this from recent painful experience.
Packaging: this is a very old method that predates the metadata API on which both Ant and Eclipse rely. In our experience, packaging's only benefit is in defining your project. If you're using Eclipse (which we do, and I recommend), you can define your project as being based on a particular package. As long as you remember to add new components to your package, your project hangs together
One thing that baffled us for a while, btw, are the many uses of package. We've noted the following:
Installed packages: these come in managed and unmanaged flavors and are really, in the words of a recent post on the SFDC boards, for ISVs to deploy their stuff into various unknown orgs "out there". Both managed and unmanaged packages have limitations that make them unsuitable and unneeded for deployment from development to production within an org, or in any case where you're doing custom development and don't intend to distribute code to a large anonymous base.
Non-installed packages: this is what you see when you click "Packages" in the web UI. These, that we sometimes call "development packages", seem to be just a convenient way to keep a project definition together.
Anyway, the conclusion I'm coming toward is that our team (custom development, not an ISV) does not need packages in any form.
The other forms of deployment, both Eclipse and Ant, rely on the Metadata API. In theory they are capable of exactly the same things. In reality they appear to be complementary. The Force.com migration tool, built into the Force.com IDE for Eclipse, makes deployment as easy as it can be (which is not very) and gives you a nice look at what it intends to deploy. On the other hand, we've seen Ant do some things the IDE could not. So it's probably worthwhile to learn both.
The process we're leaning toward is to keep all our projects in SVN, and use the SVN structure as the project definition (Eclipse will work with this and respect it). And we use Eclipse and sometimes Ant for migration. No apparent need for packages anywhere.
By the way, one more thing to be aware of -- not all components are migratable. Some things must be reconfigured by hand in the target environment. One example would be time-based workflows. Queues and Groups also need to behand-created, I think. Likewise the metadata API can't directly process field deletions so if you deleted a field in your source, you need to delete it by hand in the target. There are other cases as well.
Hope that's useful --
-- Steve Lane

As of Spring '09, mail merge templates are not supported in metadata but record types are. You will find record types as an XML element in the file for the object they belong to. Everything else on your list is supported with a small exception. Picklist values for standard fields cannot be edited in Spring '09. Stay tuned for news on Summer '09 feature announcements.
Update: Standard picklists on standard objects are now metadata exposed (as of API v16):
http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_picklist.htm
Otherwise, Steve Lane's response is pretty accurate. The advantage of using unmanaged packages (what Steve calls non-installed packages) is that when you add metadata to a package, the metadata it depends on will automatically be added. So it's easier to grab a full set of metadata containing all its dependencies. If you are repeatedly moving metadata from one org (sandbox) to another (production), Steve's approach is probably the best way to go and certainly the most common today. I frequently use unmanaged "developer" packages to move something I've developed in one org to another unrelated org. For my purpose, I like to have the package defined in the org as opposed to an Eclipse project / SVN. But that probably doesn't make sense if you are doing team development across many dev/sandbox orgs and are using SVN already.
Jesper

Another option is to use Change Sets if you want to move meta data from a sandbox to production.
There are currently some limitations on how change sets can be used:
Sending a change set between two organizations requires a deployment
connection. Currently, change sets can only be sent between
organizations that are affiliated with a production organization, for
example, a production organization and a sandbox, or two sandboxes
created from the same organization.

From the docs:
A package must be managed for it to be published publicly on AppExchange, and for it to support upgrades. An organization can create a single managed package that can be downloaded and installed by many different organizations. They differ from unmanaged packages in that some components are locked, allowing the managed package to be upgraded later. Unmanaged packages do not include locked components and cannot be upgraded. In addition, managed packages obfuscate certain components (like Apex) on subscribing organizations, so as to protect the intellectual property of the developer.
Advantage to managed package would be that it allows you to easily version and distribute things across multiple SFDC organizations.