I am trying to add a universal package feed as upstream source for another universal package feed in a different ADO project (but same org) but I do not find in the UI the right buttons.
According to this documentation it should be possible to upstream in the same org: https://learn.microsoft.com/en-us/azure/devops/artifacts/how-to/set-up-upstream-sources?view=azure-devops
Am I missing something here?
Universal Packages does not yet support upstream sources, but will very soon (no dates to share, sorry). If the docs suggest otherwise, they may have gotten out ahead of us.
Related
We've published a package with two artifacts in it (android and os) to Bintray: https://dl.bintray.com/gojuno/maven/com/gojuno/commander/
Then we've enabled sync with jcenter for this package, but only one of the artifacts is in sync (android is synched while os is not):
https://jcenter.bintray.com/com/gojuno/commander/
I contacted Bintray through Inbox on bintray.com, Contact Us on bintray.com, Email and Twitter and haven't received reply anywhere, this issue is blocking for the project.
I saw similar issue was resolved through StackOverflow Bintray and JCenter not in Sync, so this is my hope.
An inclusion to JCenter always uses an allocated path prefix to avoid accidental file overwrites by other users. However, the 'commander' package contains files with no common base path:
'/com/gojuno/commander/os' AND '/com/gojuno/commander/android'
The best practice we recommend is creating a new package and not creating more than one path prefix for a package. If you wish keep working like this, please note that you will have to submit an inclusion request for each path prefix.
As for now you may proceed working on the same groupID path prefix with your different sub-modules.
We hope this clarifies.
usually when changing the artifact path you won't be able to resolve your content through JCenter although it was previously included.
The reason for this is that the inclusion of your 'commander' package in JCenter is for the files’ path.
Therefore, it was originally included under the path prefix 'com/gojuno/commander/android/'.
However, we have re-linked your package on the GroupId level (com/gojuno/commander) so every sub-module of your 'commander' package, will be added automatically and be synced with JCenter.
I am not able to setup SVN in Xcode 5.
Iv tried these steps:
1) Goto-Xcode-Preferences-Accounts-Add Repositories (clicking "+" sign).
2) Enter the url to common server and click next.
3)Enter the credentials. At this point of time i get this error message
When i click ok i get this screen
Where do i go from here. No other Option left.
The source control seems to be like this.
Recommendation
I've answered a similar question here and provided references in my earlier answer. Generally speaking you should have been authenticated to the repository (if password is required) and then presented with a target directory. Please note that I am using Xcode 5.0.2 (5A3005).
You could also try importing a sample svn from an offline resource such as the one referenced in the image below. This would help you with validating that everything is correct on your machine/installation. At that point, I'd recommend extrapolating to see how your specific project might be different.
If all else fails you can go to Terminal and use the SVNBook resource from my other question to manually create a local SVN repository and then simply add that to your project. You could then work on adding a remote repo after you have the basics working.
My recommendation is use SVN via commands you can do this by download command online tools this is more reliable then GUI base tool.
When I checkout files from tfs the modified date of the files get set to "now" (checkout date and time).
This behaviour, however, is not wanted from me for files that belong to purchased 3rd party controls from other software vendors. If I distribute these files to customers then I can't reliably check which version of the file is installed if there is a problem.
I know that tfs 2010 will have an option where you can select the desired strategy, but until then I need a different workaround. anyone else had this problem? how did you solve, or get around it. any advice is welcome, thanks!
One possible work around is to look at wrapping all third party files and controls within a class library and embedding any binary files within either that project resources or assembly file, you can then extract them as required when the program runs (example here).
As your project is under version control you will know exactly which file is in use by the version number of your project.
We have an automated build and QA process for our software, using tfs/teambuild and msbuild, and we want to be able to know (for audit purposes) whether a component has gone through that process or not.
For example, if a library is installed on a user's machine, I'd like to be able to inspect it in some way to tell that it went through the build. In particular, I want to be able to distinguish it from components built directly on a developer's machine, and then manually installed.
What is the best way to do this? Code signing as part of the build process seems closest to these requirements, but presumably this would not cover any 3rd-party libraries that might be used? I also read about the ILMerge tool to merge all assemblies into one, but then I don't know enough to work out whether they can then be signed or not?
I'm sure we're not the first people to have the requirement, so casting around for any ideas or hints from others who might have done such a thing
Thanks!
Our developer builds are set to keep the versions at "0.0.0.0", but our build server marks the build based on a pre-configured version and automagically generated build string. "1.0.3.xxx". Your build server doesn't allow for this?
Your build process should be updating each of your projects assemblyinfo.cs files (or a global linked equivalent), you can do this with the TFS changeset number, so like the previous poster indicated you end up with the property on each dll of 1.0.changeset.buildno or something similar. You can do this easily in msbuild.
You could have the values of each assembly info file set in source control to be something obvious like 0 or 999.
A lot of what your asking is about process and training as well though.
If your using installers or zips to package your deliverables then you can also label them with the build number as part of your build process.
But if you have changeset you have the link from dll to code, so traceable, coupled with links to third party dll references as defined in each csproj.
I'm just getting started with the team build functionality and I'm finding the sheer amount of things required to do something pretty simple a bit overwhelming. My setup at the moment is a solution with a web app, an assembly app and a test app. The web app has a PublishProfile set up which publishes via the filesystem.
I have a TFS build definition set up which currently builds the entire solution nightly and drops it onto a network share as a backup of old builds. All I want to do now is have the PublishProfile I've already setup publish the web app for me. I'm sure this is really simple but I've been playing with MSBuild commands for a full day now with no luck. Help!
Unfortunately sharing of the Publish Profile is not supported or implemented in MSBuild. The logic to publish from the profile is contained in VS itself. Fortunately the profile doesn't contain much information so there are ways to achieve what you are looking for. Our targets do not specifically support the exact same steps as followed by the publish dialog, but to achieve the same result from team build you have two choices, I will outline both here.
When you setup your Team Build definition in order to deploy you need to pass in some values for the MSBuild Arguments for the build process. See image below where I have highlighted this.
Option 1:
Pass in the following arguments:
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;PackageTempRootDir="\\sayedha-w500\BuildDrops\Publish";AutoParameterizationWebConfigConnectionStrings=false
Let me explain these parameters a bit, show you the result then explain the next option.
DeployOnBuild=true:This tells the project to execute the target(s) defined in the DeployTarget property.
DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder: This specifies the DeployTarget target.
PackageTempRootDir="\\sayedha-w500\BuildDrops\Publish": This specifies the location where the package files will be written. This is the location where the files are written before they are packaged.
AutoParameterizationWebConfigConnectionStrings=false: This tells the Web Publishing Pipeline (WPP) to not parameterize the connection strings in the web.config file. If you do not specify this then your connection string values will be replaced with placeholders like $(ReplacableToken_dummyConStr-Web.config Connection String_0)
After you do this you can kick off a build then inside of the PackageTempRootDir location you will find a PackageTmp folder and this contains the content that you are looking for.
Option 2:
So for the previous option you probably noticed that it creates a folder named PackageTmp and if you do not want that then you can use the following options instead.
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;_PackageTempDir="\\sayedha-w500\BuildDrops\Publish";AutoParameterizationWebConfigConnectionStrings=false
The difference here is that instead of PackageTempRootDir you would pass in _PackageTempDir. The reason why I don't suggest that to begin with is because MSBuild properties that start with _ signify that the property in essentially "internal" in the sense that in a future version it may mean something else or not exist at all. So use at your own risk.
Option 3
With all that said, you could just use the build to package your web. If you want to do this then use the following arguments.
/p:DeployOnBuild=true;DeployTarget=Package
When you do this in the drop folder for your build you will find the _PublishedWebsites folder as you normally would, then inside of that there will be a folder {ProjectName}_Package where {ProjectName} is the name of the project. This folder will contain the package, the .cmd file, the parameters file and a couple others. You can use these files to deploy your web.
I hope that wasn't information over load.
The ability to publish web sites, configure IIS and push schema changes for the DEV->QA->RELEASE cycle has required either custom configuration to imitate publish or custom code where IIS settings are involved.
As of Visual Studio 2013.2 Microsoft has added a third party product that manages deployment of web sites, configuration changes and database deployment with windows workflow and would be the recommended solution for automating deployment from TFS build.
More information can be found here:
http://www.visualstudio.com/en-us/explore/release-management-vs.aspx
You can use the Publish/Deploy in Visual Studio 2010.
See http://www.ewaldhofman.nl/post/2010/04/12/Auto-deployment-of-my-web-application-with-Team-Build-2010-to-add-Interactive-Testing.aspx for more information