I have almost 10+ Projects created in Watson Data Platform.
I created a Data Catalog and added some data assets csv.
Now i am trying to add the dataset to existing projects.
But it only shows one project out of my 10 projects.
Can you please help?
Thanks,
Charles.
I found out following:-
This screen lists/pulls all projects that are restricted, all projects that are bluemix COS types, all projects you have permissions to.
Restricted means Under Project Settings -> Project Scope should be restricted to who can collaborate should set to Yes. The same option is being asked when you create the project. It restricts only users who are part of your Bluemix Organization to be added as collaborators.
Also the project should be using Cloud Object Storage as Storage.
Hope others find this useful.
Thanks,
Charles.
Related
I'm trying to download my project from Visual Studio Online (TFS), but I can't see one project in list. I have two accounts, main and secondary. I'm trying to get project using secondary account. Both users have Administrator permission on this project. Also, other projects, that I see in list, have same permissions with this account. I see this project on web-site (my_organization.visualstudio.com), but it is not in Visual Studio, in Source Control Explorer. Need some help - is there any bug, or I'm doing something wrong..? Thanks
Stackoverflow is mainly handling issues’ open forum while your current question is organization identity/account issue targeting to Azure DevOps, which need assistance of the product group. Thus the best contact channel is here: https://developercommunity2.visualstudio.com/report?entry=problem&space=21, the product support engineer will then contact the product group and offer efficient assistance. Thanks for your understanding.
BTW, you could refer to this doc: Set repository permissions for Git or TFVC to check your account's repository permissions in this project.
I searched all over the web but all i can see is Git! Maybe i got it all wrong but what i am looking for is a mechanism for creating a complete development team for my iOS app project. It should consist of a two team managers and team members. Each team member would get access to a limited number of files and resources and the team managers can overview and modify the changes made to the project by the members. I am sure part of this is done through Gits but how do i handle the access definition and team work part with Git?
Assuming that you have access to a server on which you can define bare repos:
the lightweight tool for fine-grained access control level is gitolite (perl, with lots of access rules, no database required)
the more complete solution would be GitLab CE (Git repo hosting in ruby, with a large permission matrix)
or, more recently: Gogs (Git repo hosting in Go)
The last two work with a database for user definition.
I have a project in Xamarin.iOS and I want to build it for different clients under different app ids with unique icons for each client. What is the best way to do this ?
There are many (many...) ways you could do this.
An easy one would be to create several application projects (.csproj) under the same solution (.sln).
Each project would have it's own configuration, defines, targets, even files (like icons). All sources would be links (i.e. file linking) from the master project.
That would allow you to customize/brand, build and publish each application separately, while maintaining a single code base across all of them (from a single solution).
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
We're starting to user Team Foundation Server and my boss would like some way to "archive" projects. Meaning after they are completed, remove them from an "active" state so that only "active" projects are visible.
Does anyone have any experience with this?
I've thought of 2 options.
1) Create 2 base projects. 1 for active projects and 1 for achived projects
2) Remove all users from the archived projects.
Thanks,
Sam
I would personally recommend waiting for TFS 2010 when more functionality will be introduced that will assist you in the ability to "archive" Team Projects.
In TFS 2010 you will hopefully be able to move a team project to a new Team Project Collection. Actually you do this by duplicating your "active" project collection and then deleting all the team projects from it apart from the one that you want archived. In this active project collection, delete the archived project that you have a copy of in the duplicated project collection. This archived team project will then live in it's own project collection which means it has it's own database etc which can be easily backed up / archived etc.
The archived team project project collection can then be left as it is as it doesn't slow down the server any if not being used - or it could even be detached from the TFS Application instance so that it doesn't show up at all and re-attached at any time.
An advantage of using project collections in TFS 2010 is that full Version Control and Work Item Tracking history will be maintained.
I would use it just as you normally do, but when you are done with the project then you remove it from the visible list. (In Visual Studio you can right click on a project in the team explorer and say remove.)
If you are worried about changes after the project is done, then remove the users from the contributors list. If you really want to boot the users out (so they cannot even see it) then you can deny them rights to the project.
This way you don't have to see it, but you can keep all your projects on the base level.
I would NOT recommend having just 2 base project for active and in-active. A TFS project should not be based on a state.
We created an "Archive" team project and we regularly move unused source code to that team project. It has worked out well for us, the history is preserved so we can always reference the archive project for old code or information on past changes. We also limit access such that developers have read access but only TFS administrators have write access. I haven't checked to see how these moves impact the association of check-ins with work items - mostly because everything we archived was checked in before we moved to TFS.
As for the one active team project, I was led to believe by knowledge experts and online documentation that this wasn't the best way to organize team projects. I think ideally you group projects/solutions together into a single team project if they are related (i.e. by line of business or dependencies).
I'm sure you've already done your research, but there is plenty of documentation out there that might assist (especially if your team maintains a single application or a handful of applications). I would suggest starting with patterns & practices: Team Development with TFS.