how can i have scheduled builds to run only when there were changes in the source code since the last scheduled build?
Like as it was with the old xaml based version.
In new build system of TFS 2015, scheduled build doesn't have the option "Build event if nothing has changed since previous build".
As an alternative, you can use CI build instead of scheduled build. Meanwhile, I have submitted a UserVoice at website below, you can vote it, Product Team will evaluate it carefully:
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/16300498-add-build-event-if-nothing-has-changed-since-prev
Related
I've written a VS 2022 Extension containing commands that I'd like to run at the launch of Visual Studio 2022.
The command run fine if executed from a menu item but I cannot determine where a call to the command should be placed if I wish it to be called immediately after VS 2022 starts.
The VS commandfile functions New() and InitializeAsync() do not appear to be called until the first command is launched by a menu item (because the extension isn't loaded until called upon).
Is there a method of making the extension ready/initialized so it can run a command at startup, or to run the command at startup and force it to initialize?
You can configure an AsyncPackage to auto-load with the instructions here. Note there is some asynchrony so if you need it to run precisely at certain point you may have issues; we limit the ability for that because when everybody writes their package to do something on startup, Visual Studio startup then takes forever.
I just want to know something about Katalon Studio. I have not worked in automation testing before but now I have some assignment about testing in Katalon.
My client wants to test in Katalon but his requirement is that he wants to run test cases on every build automatically and he also doesn't want to install Katalon IDE or any library he just want reference so that he just added that reference on every build so that all the test cases run automatically on every Dev build.
Is this possible using Katalon? Kindly help me, please. Thanks.
You have to establish full CI Pipeline for your requirements. My advice is, to use Katalon with Jenkins and your developers code repository (perhaps GIT or SVN). Than you are able to implement a server/slave pipeline, where you can execute your Katalon scripts on slave, every time DEV builds.
See:
Katalon/Jenkins Tutorial
Just recently uninstalled VS2017 RC and installed VS2017 RTM.
We have a Windows Service solution which includes a Setup project.
When I build this in Visual Studio 2017, somehow it's triggering something in the installer for Visual Studio 2013 (which we're still using), as I get this popup appearing:
It's fairly reproducible, but I have no idea where to start with this one.
Any ideas how to stop it happening?
It didn't happen before with the release candidate.
EDIT:
So, several VS2017 updates later, this problem had got a lot worse, as it was stopping me building the setup project completely. Previously I was able to click cancel as in my first screenshot, but at VS2017 v15.3.3, it wouldn't cancel, and if I let it run, it hung at:
So this forced my hand somewhat. I've accepted #PhilDW's answer as he led me straight to the main clue, but I'll also add an answer of my own with more detail.
As in PhilDW's answer, I checked the event log, and found this:
Detection of product '{9C593464-7F2F-37B3-89F8-7E894E3B09EA}', feature
'Visual_Studio_Professional_x86_enu', component
'{E3FF99AA-78B9-4A06-8A74-869E9F65E1FE}' failed. The resource
'C:\Windows\Microsoft.NET\Framework\URTInstallPath_GAC\' does not
exist.
A little Googling, and I found this MSDN blog entry:
Workaround
We are consistently seeing this issue caused by a missing directory,
C:\Windows\Microsoft.NET\Framework\URTInstall_GAC (or
%SystemRoot%\Microsoft.NET\Framework\URTInstall_GAC).
To work around this issue,
Open an elevated command prompt.
Type: mkdir %SystemRoot%\Microsoft.NET\Framework\URTInstall_GAC
Note that the folder name isn't the same as in my case. I didn't notice this initially, and creating the folder didn't cure the problem.
However when I created the actuall folder referenced by the event log message, the problem went away, and I can now build my setup project without messages about VS2013.
It's a repair of Visual Studio 2013 because Windows thinks the install is broken (registry entries or files not as in the original VS 2013 install). If you look in the Windows Event log, Application, there should be some MsiInstaller log entries that tell you the product (by ProductCode guid) and the broken component (by component guid and file or registry name). This might help identify what's going on, but not necessarily have a clue to a fix. If it's a setup project it might be a conflict with mergemodule Dlls or prerequisites, some of which come from the current SDK.
You don't say if you're letting the repair complete, in the case that it's just an isolated occurrence.
I am not looking for Definitions for all these terms but interested in knowing "How Developers work when they are developing some software in ASP.net"
My senior has divided the project in 2 folders .first one is Development:D second is Subversion:S folder.Both folders contains same files.
While programming(development)on which folder should I work.( i mean on which file should I open to start programming : D folder or S folder ).
We are using Subversion and visual studio 2010.
If any one could explain me "Deployment scenario " then I would be very thankful to them.
Thanks.
We use SVN at our site (TortoiseSVN as client).
Each project has its own repository with three types, a Trunk, a Releases branch, and Branches. Trunk is a work in progress, Releases are snapshots of the source for major releases, and a new Branch gets created for a particular task. Upon completion a branch will get merged back into Trunk, and eventually a release gets created from Trunk.
Development phase and Production phase seem confusing, but I'm guessing development means code in the process of being developed, and production means code that has been released into the production environment. You generally don't want to do development in the production environment, you should start in development phase and once the functionality is thoroughly tested, promote it to production.
Net solution for a website, consisting of 5 projects, and there are a few(less than 10) developers working on the solution. We deploy almost on a daily basis.
The question is, how to setup the SVN repo to support this scenario (the daily deploy), also mentioning that not every commited file should go to production, there is a QA check before deploying.
Try out TeamCity
(CI tool) as its free for smaller amounts of CI. this may be better for you than CruiseControl.Net as CCNET is very configuration heavy as its all done via XML. TeamCity uses wizards to create the scripts to manage releases
if you need any other help on CI then let me know as its something I am evangelistic about.
What you want to do is commonly referred to as Continuous integration (CI).
While you can do that using Subversion, it is probably not the right tool for the job.
There is special CI software, which will allow you to easily automate the necessary tasks (checkout from version control, compiling / building, running automatic tests, deployment etc). An example would be CruiseControl.NET.
As to "not every commited file should go to production", the common solution is to have a special "release" branch, which gets deployed. Only tested code is merged there (or have the trunk always be stable, otherwise same model). Of course, you can also (better: additionally) have tests before your automatic deployment, and only deploy if all tests pass.
Working with a release branch
In practice, this means that people check in their code as they produce it. Sometimes this code will work, sometimes not. When the release time draws nearer, a "release branch" is created in Subversion. This release branch is then effectively a frozen snapshot of the source as it was at the time of branching. Now this branch can be used to compile & deploy the application, which can then be tested.
No new code is checked into the branch (but checkins can continue elsewhere). Only if a bug is detected in the branch, will there be a checkin into the branch to fix it. This continues until the branch passes all tests. Then the branch can be released as a new version of the software; afterwards the branch will only be used if the released version needs to be patched.
Of course, any bugfixes checked into the branch need to also be put into the trunk (either by merging branch -> trunk, for which Subversion provides special support, or by reimplementing the fix in the trunk, as appropriate).