How to configure hub uri to mvc controller in tfs 2017 extension - plugins

I try to add extension to tfs 2017.
I created mvc web application and uploaded assembly to bin directory to tfs (and it normally opened by direct link "http://currentip/tfs/{collectionname/{projectname}/controllername" being processed in controller and displaying view)
Also I added hub group and hub, that normally displayed.
When clicking hub I need to be redirected to relative uri like http://currentip/tfs/{collectionname/{projectname}/controllername
But now I'm always redirected to http://ip/tfs/{collectionname/{projectname}/_apps/hub/extensionname-hubgroup-hub.
How can i configure link of hub to redirect to my controller in the same server?
ps. I made attention to "base uri" core parameter of extension. But there is too pure info about it on official help page.

uri path (relative to the extension's baseUri) of the page to surface as the hub.
You could set only *.html files(html page to be used for your hub) that described in the your extension's manifest file: vss-extension.json . Can't not configured the detail uri yourself. Since it will be loaded from VSTS or TFS server.
Actually baseuri is used for local debug/develop your extension. Without this, for every small change you make, you need to completely redeploy the package and then use your browser to validate the changes.
When you add this property, you override the default location of your assets. By letting this property point to your local host you can serve the files locally and your extension will load them into the context of VSTS or TFS.
After you finished with development, just remove the baseUri from your manifest file and publish the extension to the marketplace. Afraid this is not helpful in your case. More details please refer this tutorial: Using BaseUri to develop your VSTS extension

Related

how can i reflect changes from AEM author server to publish server?

I am new to AEM. and I have two instances of author and publish.
how can I reflect my changes from author to publish.
I have tried from frontend but it didnt work for me..
-Thank you
I'm not sure what your exact problem is. But to view your changes you need to publish your pages or workflow in the author instance, once it is published open your publish instance. Now in browser edit the URL of the publish instance to your website and the page you want to visit. That should work for you!
You can refer the documentation here: Publishing Pages
you will only be able to see the changes reflected after creating a package of your project you wish to see on publish instance. I will guide you through the steps that should be followed while publishing your pages and sites from author to publish instance.
1.Create a replication agent on author by filling all of the required fields like mentioned below:
you have to provide your Publish instance uri
use it enter link description here
2.Then you have to test connection after starting publish instance
3.Then create a package of your project and install it on publish instance.
4.Now when you'll open your publish instance you'll be able to see default we retail website mapped on your publish instance. You can map your website url in following manner.
open your publish instance and visit enter link description here
Search Day cq root mapping and provide your web page url you want to map for example:
5.And then when you'll run your publish instance youll be able to see your site like this:

Change Artifacts Explore Link in Visual Studio Team Services

I have successfully created a build within Visual Studio Team Services. One step of the build is to copy the outcome (artifact) to a Drop Folder which contains all versions of the artifact for that build. So far so good.
As you can see in the following image. I am using a File share as the Artifact Type and then I specify the path where the artifact has to be copied.
Now the issue. When I go to the build summary and click on the artifact tab, I can see the explore link. Clicking on that link will pop up the following:
The browser cannot open the following location due to this browser's
security settings. You will need to copy the location and open it
manually.
The location is: file://BuildServer/BuildDrops/MyArtifactName/[version
here]
OK to copy the location to your clipboard.
So I set up an FTP server in such a way that the ftp://BuildServer/BuildDrops/ URL is pointing to the same path specified in the Copy Publish Artifact build task.
But I see no way to modify the link to use my custom URL.
Ideally, the Copy Publish Artifact task should accept a variable, let's say, Artifact Link Base URL so I can pass the value for the base URL and the link will use this value instead.
Anyway, my question.
Is there any way to modify the link whatsoever?
There isn’t the way or feature to modify the artifact link URL in Visual Studio Team Services.
You can build a custom extension (https://www.visualstudio.com/en-us/docs/integrate/extensions/overview_ to build a FTP URL according to build artifact download URL, then generate a hyperlink to navigate to corresponding FTP site.
Extension sample for build results: https://github.com/Microsoft/vsts-extension-samples/tree/master/build-results-enhancer

Is there any way to check in items or create a new project from files via the API?

We're starting to automate some of our project kickoff processes. We already have a project management app (built in-house) that creates the base Solution and C# project with some default screens, authentication, etc. and populates some standard data like App Name and Namespace.
Ideally, what I'd like to wind up with is clicking a button in our project management app, having it create a VSTS project for the app, pull the template files and manipulate them as-needed, and check it all in to VSTS as a "ground zero" changeset for that newly created VSTS project. At that point, our dev team can just connect to the project and pull it down in Visual Studio.
From what I'm seeing in the REST APIs documentation for VSTS, you can get a list of changesets and files associated with a changeset, but I'm not seeing any references on adding or checking in files.
Is this something that can be done via the APIs, or some other automated extension mojo?
You can use Rest API to create a new project.
For Version Control, since you mentioned "check in as changeset", I assume you are using TFVC. The Rest API can only get the information about TFVC version control, it cannot check in files for now. If you want to check in files via API, you can consider using .NET client libraries for Visual Studio Team Services (and TFS). Refer to this link for details: Team Foundation Version Control client API example for TFS 2010 and newer. It works with VSTS too.

How to download a web.config file via the VSO rest api from a TFVC repository

The visual studio online rest api has a rest call to download the contents of a file in a TFVC repository. I want to download the latest version of all my TFVC repositories to have an on-premise back-up of all our projects.
This APi works great except for one type of file: web.config. When I want to download the web.config file I get a 404 statuscode. All other filetypes (also log4net.config and web.release.config) download correctly and I also get a 202 there. I have the correct permission to download the file and the file also exist.
I use the api as documented here: https://www.visualstudio.com/integrate/api/tfvc/items#Getafile
As you can see the path to the file in the repository is part of the URL. I think with this syntax, Visual Studio Online default security comes in way of files like web.config. In e.g. IIS the download of a web.config file is also disabled. For our git repositories this is no problem because that api doesn't include the path to the file in the url but as parameter of the url.
Is there a way around this? An undocumented feature?
When I see this documentation https://www.visualstudio.com/integrate/api/tfvc/items#Getaspecificversion it mentions:
You can indicate which version to get when you get a file, zip a folder, or get item metadata.
That zip a folder part is not (yet) documented. Does anybody of you know how to call that part of the api? That would also be a workaround for me.
This is now possible when you use the path as query parameter
This format should be used for certain files (like web.config) that are not accessible by using the path as part of the URL due to the default ASP .NET protection. The response is a stream (application/octet-stream) that contains the contents of the file.
http://fabrikam-fiber-inc.visualstudio.com/defaultcollection/_apis/tfvc/items?path=$/fabrikam-fiber-tfvc/website/website/web.config&api-version={version}
The above quote is from the documentation after this is added: https://www.visualstudio.com/integrate/api/tfvc/items#Getafile.

Azure Continuous Integration Overwriting App_Data even with WebDeploy file specified to "exclude app data"

I have a Windows Azure Website and I've setup Azure Continuous Integration with hosted Team Foundation Server. I make a change on my local copy, commit to TFS, and it gets published to Azure. This is great, the problem is that I have an Access database in the ~\App_Data\ folder and when I check-in the copy on Azure gets overwritten.
I setup a web-deploy publish profile to "Exclude App_Data" and configured the build task to use the web-deploy profile, and now it DELETES my ~\App_Data\ folder.
Is there a way to configure Azure Continuous Integration to deploy everything and leave the App_Data alone?
I use the 'Publish Web' tool within Visual Studio, but I think the principles are the same:
if you modify a file locally and publish, it will overwrite whatever's on the web
if you have no file locally - but the file exists on the web - it will still exist on the web after publishing
The App_Data folder gets no special treatment in this behaviour by default. Which makes sense - if you modified an .aspx or .jpg file locally, you would want the latest version to go on the web, right?
I also use App_Data to store some files which I want the web server (ASP.NET code) to modify and have it stay current on the web.
The solution is to:
Allow the web publishing to upload App_Data, no exclusions.
Don't store files in App_Data (locally) that you want to modify on the web.
Let the web server be in charge of creating and modifying the files exclusively.
Ideally you would not have to change any code and the server can create a blank file if necessary to get started.
However if you must start off with some content, say, a new blank .mdf file, you could do the following:
Locally/in source repository, create App_Data/blank.mdf (this is going to be a starting point, not the working file).
In Global.asax, modify "Application_Start" to create the real working .mdf file from the blank starting file:
// If the real file doesn't exist yet (first run),
// then create it using a copy of the placeholder.
// If it exists then we re-use the existing file.
string real_file = HttpContext.Current.Server.MapPath("~/App_Data/working.mdf");
if (!File.Exists(real_file))
File.Copy(HttpContext.Current.Server.MapPath("~/App_Data/blank.mdf"), real_file);