I am currently involved in building an extensive custom control suite in XAML/C++ which which will be a 'paid-for' package, which will be available to Metro XAML developers for a licence fee.
I want to allow customers to purchase a licence via our company website, then access their purchase via Nuget within Visual Studio.
My questions are:
1) Can I utilise the NuGet packaging technology for 'paid' components (users will need to enter credentials or licence key to get them from our private Nuget repository - or something similar)
2) We would want to host our own Nuget repository to control access, and hope to hook into our TFS system - does anyone know if this is possible ?
The scenario we are trying to create is where a potential customer comes to our website, buys our control suite, downloads our controls (securely) in Visual Studio via Nuget and gets automatic updates. On the flip side, we do all of our development to TFS, press a 'deploy' button and the update gets automatically published to our TFS-based Nuget repository.
I know this is a complex multi-faceted question, but any suggestions would be welcome :)
First of all, NuGet is not supposed to contain any built-in security mechanisms - it is simple zip archive in OPC format. Once your client took a package he can send it to anyone. You can sell a service - freshest releases, bug-fix support and so on.
What about practice. You can implement NuGet API And Share to your customers only feed.
Do Any authentication you want.
Create as much feeds as you need (according to your licensing policy).
Every feed will contain only subset of your packages
Create a package on-the-fly with built-in customer key (it goes against moral rules of the project) - cause package doesn't have a signature.
But this gives you ability to enable to customer to use NuGet as a platform to update your packages along with any shared packages.
AFAIK, there is no public gallery for NuGet (Nuget Gallery, Nuget.Server, and so on) wich will restrict access to the packages.
Related
We are using TFS 2018 (2018.1 to be precise). I need to find out how many projects are using a particular TFS Extension. How can I get this information? Few of these extensions are installed through Visual Studio Market Place and few are developed internally.
Actually, when you install a extension, you need to specify a collection, the extension will be installed for all team projects under this collection.
In other words, extensions are installed into the collection level, it's not able to use extension for a specific project. All projects in the collection are installed.
You could take a look at our official link here: Install extensions for on-premises servers
For now, only with for a paid extension, you can restrict who can access it by Assigning paid extension access to users.
Update
However, to find out the number of builds or projects using a particular TFS extension is not available at present. There's no such build-in feature.
You could submit a feature request in Azure DevOps Develop Community site.
Our PM will kindly review your suggestion.
In my team we are using TFS for code review. Unfortunately the UI in VS Team Explorer and the Team Foundation Web interface are pretty ugly and unfriendly, e.g. dlls packages need to be collapsed one by one and that makes Code Reviews tedious as you end up having to chase the relevant code.
Is there any way I can exclude files (e.g. DLLs) or have more advanced filter (e.g. exclude comments, white spaces, new lines)?
Thanks
There is no way to simply exclude source controlled DLLS from Code Review.
Daniel is right, for this kind of external dlls, the best and clean way is via the package management solution such as NuGet. There is an excellent extension called-- Package Management in TFS. It's not hard and will not take too much time to do this.
Package Management is an extension that makes it easy to discover, install, and publish packages. It's deeply integrated with other Team
Services and TFS hubs like Build so that package management can become
a seamless part of your existing workflows.
For more details, you could have a look at this tutorial-- Package Management in Team Services and TFS
Besides, there is also not any built-in advanced filter (e.g. exclude comments, white spaces, new lines). The official tutorial for your reference: Get your code reviewed with Visual Studio
You could also try to use some 3-rd party extension in VS such as this one: Review Assistant - Code Review Tool which also support TFS integraton.
We are just beginning development and implementation for dynamics crm 2011 on premises. Is it possible to implement automation for code check-in to promote code from development to test systems? It looks like this would involve export/import of unmanaged solutions containing the development code that was checked in. I have not been able to find APIs around this functionality.
If that is not possible, how close can you get? It looks like there are APIs to automate the uploading of web resources and plug-ins (e.g. webresourceutility in the sdk), but the web resources still need to be manually linked to the form they are to be used on (in the case of javascript etc). Has anyone made progress in automating parts of their CRM environments?
for reference, we're using vs 2010 & tfs 2010 using MSuild for current continuous integration.
We have a few techniques that provides us a very solid CI structure.
Plugins
All our Plugins are CI Compiled on Check-In
All plugin code we write has self-registration details as part of the component.
We have written a tool which plays the Plugins to the database, uninstalling the old ones first based on the self-registration
details.
Solution
We have an unmanaged solution in a Customisation organisation which
is clean and contains no data. Development is conducted out of this
organisation. It has entities, forms, Jscript, Views, Icons, Roles,
etc.
This Customisation database has all the solutions we've imported from 3rd parties, and customisations are made into our solution which is the final import into a destination organisation.
The Solution is exported as managed and unmanaged and saved into
TFS
We store the JScript and SSRS RDLs in TFS and have a custom tool
which plays these into the customisation database before it is
exported.
We also have a SiteMap unmanaged Solution which is exported as unmanaged (to ensure we get a final resultant Sitemap we are after)
Deployment
We have a UI and Command Line driven tool which does the following :-
Targets a particular Organisation
Imports the Customisation managed solution into a selected environment. e.g. TEST. Additionally imports the unmanaged Sitemap.
Uninstalls the existing solution which was there (we update the solution.xml file giving it a name based on date/time when we import)
Installs/Uninstalls the Plugin Code
Installs any custom SQL scripts (for RDLs)
Re-enables Duplicate Detection Rules
Plays in certain meta-data we store under source control. e.g. Custom Report entity we built which has attachments and XML configuration.
It isn't entirely perfect, but via command line we refresh TEST and all the Developer PCs nightly. It takes about 1 hour to install and then uninstall the old solution per organisation.
We use CI extensively for Dynamics CRM. For managing solutions, I would recommend using a "clean" Dynamics CRM implementation which will be the master for your solutions and also for your "domain data". See http://msdn.microsoft.com/en-us/library/microsoft.crm.sdk.messages.importsolutionrequest.aspx for importing solutions. Also check out - http://msdn.microsoft.com/en-us/library/hh547388.aspx
Is there any TFS Customer Relationship Web Interface available (like CodePlex) which enable customers to follow project progress with Bug Tracking (WorkItems), Discussions, Documentations, Release Upload etc..
EDIT:
TFS Web Access has not enough features for that purpose ...
If you only want to expose information about the progress of the project, the most obvious solution might be simply to extend the TFS project's SharePoint site (this is where Discussions and Documentation can easily be held) and make use of the existing Reporting Services to build required reports.
I'm asking this question because I haven't seen it documented anywhere.
We are using a combination of Team Foundation Server 2008 and Team Explorer 2005.
Is it possible to deploy a custom check-in policy that works in such an environment ?
Obviously, the custom check-in policy contains some code that must run on the client-side (in order to display help, etc.). So it should use the Microsoft.TeamFoundation.VersionControl.Client assembly that comes with Team Explorer 2005.
But, my sense tells me that, in order to be effective, a check-in policy should be enforced on the server itself (for example, to support checking-in changes from the command-line or using the raw Web Services API). So, there, it would have to run against the Microsoft.TeamFoundation.VersionControl.Client that comes with Team Foundation Server 2008.
So, is it possible to build a single custom check-in policy that takes the most recent version the Microsoft.TeamFoundation.VersionControl.Client assembly (2005 on the client and 2008 on the server)?
Or do I have to build two custom check-in policies, one for the client and one for the server ? Would that even work ?
Or do custom check-in policies only ever exist on the client side ?
The custom check-in policies only exist at client-side, and will only be evaluated client-side. If the DLL is missing on the client computer, TFS will complain, but provide a dialog that allows the user to override the error and check in anyways.
No, it's not required. However, it makes things much easier. Using the latest Power Tools you can store check-in policies in source control and have them deployed for "free."
A walkthru with screenshots is on Brian's blog:
....Since the day we introduced those features, customers have asked for a way to distribute custom components like these to clients rather than having to manually install them. Well, I'm happy to say that this new release of the Power Tools does just that!
Due to the fact that downloading custom components and running them on clients can be dangerous, there's a fair amount of care taken and some configuration necessary to enable it. Custom components for a Team Project are checked in to a new "special" folder called $//TeamProjectConfiguration. Let me show you a few screen shots and that will help walk you through how this works....