I've found a couple of similar questions on Stackoverflow, but the answers do not solve my issue. (For example the issue would be fixed in previous version. OpsHub TFS 2010 to Visual Studio Online)
Also I experience different behaviors on multiple environments so I think it's a new question. I hope someone can help me.
I have some projects on a TFS 2012 with the standard Scrum 2.2 template. I created a Visual Studio Team Services environment on my personal account for testing the migration. I created a project based on the default Scum process with the same name as the project in TFS. When I use the OpsHub tool (version 2.0.0.004) to migrate the work items to VSTS it works as expected.
screenshot of working migration
Now I create a new project on my companies VSTS environment with the same name and the same Scrum template. Apply the same rights, and try to migrate the same project to companies VSTS, validation fails with the message that "template customization or template mismatch". Details "Code Review Response - Reviewed By"
screenshot of failed validation
I exported the scrum process templates for both environments and compared the contents but they are identical.
So I have 1 project on TFS and 2 projects on VSTS with identical templates. One migration works, the other does not. I'm stuck. Any tips would be very welcome!
Thanx
I got an email from OpsHub with the solution! They released a new version (2.0.0.005) and after clearing the cache, it works! Thank you, OpsHub.
Refer this to download the latest version.
Perform following steps:
Close the OVSMU Tool if running.
Installed the latest version OVSMU-V2.0.0.005
Clear the following cache folder:
Close the OVSMU Tool as well as any instances of Visual Studio (ie. TFS related applications)
Clear the contents of the following folders (whichever ones you have)
%localappdata%/Microsoft/TeamFoundation/3.0/Cache
%localappdata%/Microsoft/TeamFoundation/4.0/Cache
%localappdata%/Microsoft/TeamFoundation/5.0/Cache
%localappdata%/Microsoft/TeamFoundation/6.0/Cache
Launch the newly installed OVSMU Tool & Configure the migration again.
Related
I'm trying to build a visual studio 2015 dot-net application which has log4net reference in the code.
When I build in Azure DevOps using Nuget restore, Nuget Tool installer, Visual studio build, Publish Build artifacts I am getting an error:
Error CS0246: The type or namespace name 'log4net' could not be found (are you missing a using directive or an assembly reference?) Process 'msbuild.exe' exited with code '1'.
Please someone suggest whether I have to add another agent or make some reference to the package/nuget in Azure DevOps. need details since I'm new to Azure DevOps.
The error message suggests that either the using is missing or the assembly could not be found, meaning that probably the nuget restoration has failed.
If you can't figure out the issue by looking at the log, the first step should be to set system.debug to true, then you might get more info about what the issue might be.
My first instinct when I don't know what's going on would alsways be to look into the s folder of an agent but I don't have experience with hosted agents and as far as I know you cannot access the working folder of a hosted agent.
So as a workaround (only if everything else fails) I would suggest to zip the s folder ("$(Build.Sources)") or special parts of it into the a folder ("$(Build.Artefacts)") and publish that zip as an artefact. Then you can download it and look at it in great detail, e.g. look at the packages folder or open the solution and see why it doesn't compile.
Problem was partly solved as there was .gitignore and .gitattribute files in my source directory which i guess had entries to ignore the third party .dlls like log4net and several folders which were not getting checked-in when i did vsts push. But there arose some other errors in vsts build now which i am trying to figure out. I will create a new thread for that.
Thanks.
For some reason I lost ability to see it in
Tools -> Manage Nuget Packages for Solution
However from the docs
I used
Install-Package log4net
in Package Manager Console
That solved the issue.
Previously I had noticed the yellow triangle against log4net In Manage Packages For Solution, and may have tried removing it via Nuget.
However it was still showing as a reference
I have the following problem: I have a Laptop with two different user accounts (UserA & UserB / they belong to the same person but have different priveleges).
UserA: can build the solution and run tests locally (Everything is working as expected)
UserB: Has the rights to publish to the specific network drive, however he cannot build the project. The reason is that the Windows user itself has not the correct proxy settings configured, and thats why the nuget packages cannot be downloaded.
I have no possibility to change the proxy settings for UserB right now (It depends on internal processes, which might take a while)
However I would have expected, that when I build the solution with UserA, UserB would not need to build it again and just can publish it. This, does not work, as soon as I want to publish, VS tries to rebuild the solution and this does not work because some dependencies are missing and cannot be loaded.
Is there any solution for this problem? I tried to make a research, however I was not really sure for the correct keywords to search for.
Edit: I have now the domain added to my UserB, but I still have some other problems. However I found out that this article is heavily related to my issue: Unable to launch Visual Studio 2015 as a different user.
When I start Visual Studio via Command Line with the mentioned arguments, more works, however I am now not able any longer to connect to my database using Integrated Security = true in the connection string. But at least I can build now. Deploying also works but I just get a 500 Server error when I try to connect to the resource.
Edit2: I needed to add the domain to my user when opening Visual Studio with the command mentioned in the link above. This fixed my problem with connecting to the database.
Actually I do not need an answer anymore for my initial question but I will not delete it because maybe someone has an answer for a person who will have the same question later on.
I am trying to complete Continuous Integration/Continuous Deployment automation for a web application project. I have been helped by a series of SO posts link1, link2, link3 and things are now running, except the upload to the hosting server is longer than it needs to be; I currently upload all files instead of just the ones that changed.
When creating the TFS2017 Build (or Release) there are many Task options, including some from the marketplace. I'm referring to, in this case, the dialogue for a Build as shown below:
I'm currently using a PowerShell script which seems a little archaic and inefficient as noted above. Do any of the tasks available to us mimic the Visual Studio 2017 Web Deploy Publish Method which runs quite nicely and quickly? If not, what can I use for an 'intelligent' upload process that checks whether or not a file must be uploaded?
Unfortunately, there is no this kind of build task could mimic the Visual Studio 2017 Web Deploy Publish Method for now.
The method trough VS IDE will dynamically check if some files need to be uploaded or not.
However through TFS build task or powershell script will not do this, just simply copy all files you assigned. Afraid there is no workaround for an 'intelligent' upload process that checks whether or not a file must be uploaded. Since we don't how VS IDE did this.
I am trying to deploy a wpf application with an embedded rdlc report using clickonce. The previous version of report viewer (in VS2015) was built-in so it was easy and convenient to use and I had no issues deploying this project.
Now since easy and convenient is not the goal anymore, in vs2017 after a failed deploy with an error message that gave me absolutely no help, I have come to realize that apparently you have to install 2 additional VS extensions and a report viewer runtime on every machine where an app uses and rdlc reports (feels like crystal reports all over again) and you have to exclude the automatically included Chinese localization files in your clickonce deployment (which cause a manifest parse error). Anyway, the instructions on MS website say that click once should have a "Microsoft Visual Studio Report Viewer" prerequisite option to select as requirement of installing your app. However, after installing the runtime on my development machine, restarting visual studio, this option is not available. Does anyone know how to get this to work?
I used Project|Manage NuGet Packages to add this package to my project.
https://www.nuget.org/packages/Microsoft.ReportViewer.Runtime.Common/12.0.2402.15
If you search with Manage NuGet Packages, there's quite a few ReportViewer related items. I'm not sure which ones are appropriate to your WPF app.
Anyway, the deployment project picked up the various ReportViewer assembly dependencies and everything seems to be working without the EXE redist from MS.
The general guidance appears to be to install Sitecore into one folder, e.g. D:\Websites\MyWebSite and then create your Visual Studio project in a separate folder, e.g. C:\Projects\MyWebProject. You would then publish your custom code into the Sitecore folder from Visual Studio (This video explains what I’m describing https://www.youtube.com/watch?v=i3Mwcphtz4w around 13 mins in).
I have the following questions:-
Do people only store their Visual Studio project in source countrol and not the Sitecore code?
The publish option from VS into the Sitecore folder only has options for adding files or deleting anything not in the VS project. How would files removed from the VS project ever get deleted without doing it manually?
We use web-deploy to publish sites to staging and live environments. In this scenario would you publish from your VS project or would you set up a way to publish the Sitecore folder (if so how)?
Is this actually a good set up to have or do you do something different?
I did a lot of research on this when we started Sitecore development a couple of years ago. I remember reading a post from Sean Kearney that made a lot of sense to me: http://seankearney.com/post/Visual-Studio-Projects-and-Sitecore
We ended up using this approach for both large and small scale projects and it has been great. You will also want to look at a couple of other tools:
Team Development for Sitecore (TDS) from Hedgehog Development (http://www.hhogdev.com/products/team-development-for-sitecore/overview.aspx)
CopySauce from Igloo (http://www.igloo.com.au/blog/copysauce-igloos-sitecore-development-utility/)
SitecoreRocks for Visual Studio
So to answer your questions:
All of your code and some of the Sitecore items are stored in source control. The approach you want to take is to only store new Sitecore items (layouts, sublayouts, templates, etc) that you create along with any items you may need to customize. You do not need to store all of the sitecore source, content or modules...just what you would need to reapply to get a fresh environment up-to-date. You can manage this manually but a tool like TDS makes this MUCH easier.
We use TDS to manage the publish/deploy to each of our environments. TDS has configurable settings for handling items that have been deleted, including the ability to move it to the Sitecore recycle bin or simply remove it. You have to be careful with this but it does work.
We use a separate build environment to assemble and run deployments using TDS and Jenkins. Basically, all of the code is retrieved from the source control system to the Sitecore server and built using MSBuild and TDS. In most cases we use a webdeploy directly to the Sitecore webroot, but for production we build TDS packages and then run them on each Content Delivery Server
We have used this setup for 7 sitecore projects so far and I am very happy with how it has worked out. We have questioned whether TDS is worth the license fee but the answer always comes back as a yes. The alternative is not very appealing for our development staff and time savings far out-weigh the costs.
Everything is stored in Source Control!... just not always in the same area as they reside on the web server. Storing the Sitecore folder in source control is a good idea as there are changes that you will have as you install modules, but you do NOT add the Sitecore folder as part of your solution/project and should really be there to pull from if need be and not something that is even tracked/monitored.
Once Sitecore is installed, create a new project that resides in the website folder and only add things like the properties folder, layouts, xml and other folders that you want. I don't even include the app_config in my project. Oh and to be clear, it's probably best to just keep the Sitecore folder as a sort of reference folder in your source control but not as part of your website trunk. We have it on the ignore list for website folder in source control. However, that being said, keep in mind that you will NEED to have it in your website folder.
Technically speaking, the recommended approach is to install Sitecore on to the server itself as a stand alone empty instance.. like using the installer with the client mode (not full) so that you get the framework for an empty site in place. Then you can create the deployment package/packages/whatever and it will all be your own code. You should really never have to mess with changing/removing the base Sitecore file system manually.
See above. Generally speaking, unless you have a reason to do so: install Sitecore as an empty instance... then manage your code/files via deployment and just leave the Sitecore folder files alone. You will have very little reason to ever touch them or the Sitecore folder itself outside of an upgrade.
Adding Sitecore itself to source control should be avoided, since you won't be deploying Sitecore as part of your implementation. For modifications to Sitecore itself, you would need a way of handling those inside your implementation, but the config patch system and other mechanisms provide the means for this.
Redundant files in the web site folder will only be a real problem in your development environment. When publishing to a demo environment or to a live environment, you will only publish the material that you actually want. And the deployment-based setup opens up the possibility of always starting from a clean Sitecore installation - as long as you include your Sitecore modifications as part of your implementation (which is not covered in the video). So there is little risk of this being a problem in real life, and the development method in the video makes eliminating this risk entirely possible.
The Sitecore installation should be handled outside of the deployment of your implementation.
It's a good setup, because the method in the video is the method Sitecore recommends for development, and it is also the method Sitecore teaches to developers in development courses. The most obvious advantages of this method are
Clean separation between your web site implementation and the Sitecore installation. There is no risk of accidentally mangling the Sitecore installation, and there is no risk of forgetting unmanaged manual modifications to Sitecore that are needed to run your site. This separation is hard to accomplish if you're not using the method in the video.
By using publishing to deploy your implementation, you know that your implementation is deployable on top of a clean Sitecore installation - and works. This means when deploying to a production or demo server in the future, things will work the same and there will be no surprises. This is very hard to be confident about if you're not using the method in the video.
To test your implementation on a different version of Sitecore, you can just deploy to a clean installation of a different version. This is very hard to test if you're not using the method in the video.
There is sample source code for the video on GitHub, along with instructions on how to set up the development environment, including the publishing parts. This sample source directly and indirectly answers some of your questions.