I have a solution in VS 2013 that have a few utility tasks that need to be done once in a while, for example rebuild some files that are embedded in the output executable.
Right now I am using a test to run these, just because it is simple to run some code from the IDE, but I don't like it – it's not a test.
My question is how would you create some utilities or commands that can be run from the IDE?
If you can make your utilities runnable from a commandline (for example, if they're in batch scripts or standalone helper executables), then you can use the External Tools functionality of Visual Studio.
Here's the MSDN page for that topic.
I don't have VS 2013 handy, but I've done this with previous versions of Visual Studio. It is a little more natural than running a test to invoke some helper utility tasks, although that works in a pinch.
You could also cobble together a pre/post-build event that runs the utility task. It's unclear what you are doing periodically, but if it's a pretty lightweight operation, it might not hurt to do it there.
You can use my Visual Commander extension to create and run commands using .NET and Visual Studio automation model in the IDE.
Related
There is an external application that executes C# libraries(plugins - my class library).
Is it possible to attach debug to my class library project in Rider.
In a Visual Studio, this is done very easily. For example, as described in this article. But how to do it in a Rider?
Thank you
Now you can use .NET Executable for your task. Put your library as command-line arguments into a run configuration. In the future, we want to add the macro for OutputPath.
Is there any way of running tests automatically after each build?
I know this is possible in 2013 Premium/Ultimate (link) but sure there are ways
to do this in the Community edition?
I'm using Nunit + adapter so it would be nice to have tests run through
the adapter instead of using post-build command-line events..?
(which I can figure out myself tbh)
IF I need to write a vsix, no problem, I'm capable of that too. Just need
a pointer in the right direction? If I should need to write one, I would
monitor files changed before build and only run the needed tests.
I'm not a professional programmer yet, I've just started college and I study some things by myself outside of it. I'm doing pretty basic stuff in C#, like console applications and simple stuff for the web in asp.net.
I've noticed that whenever I publish a C# project using Visual Studio 2010, I am obligated to use this "click once" setup wizard for my apps. But I don't really think any of them need a setup program, they are just a executable and maybe a bunch of .dlls which are able to run by just executing them right away.
I fail to see what's the poing of this click once installer? It probably checks if the correct version of the .Net framework is installed and, if not, installs it. But is that all it does? I think this click once is too ugly and if checking the .net version is all it does I'd rather code my own installer using another language which looks better and provides more info about my program.
You don't need to use ClickOnce, that's just an option for how to distribute your app. You could simply build using the Release configuration and then distribute that Release folder (typically bin\Release, configured in the project's settings), or use a post-build command to, e.g., build a zip of the assemblies and config(s) you need:
del /Q $(SolutionDir)MyApp-win.zip
cd $(OutDir)
"C:\Program Files\7-Zip\7z.exe" a $(SolutionDir)MyApp-win.zip MyApp.exe MyApp.exe.config OtherAssembly.dll
I recommend using ClickOnce for smaller apps since it simplifies the distribution of app updates alot.
You don't need to use the ClickOnce installer that is provided by Visual Studio though. You can create your own installer (with a UI that suits you more) that in turn uses ClickOnce under the hood for the heavy lifting.
See https://msdn.microsoft.com/en-us/library/dd997001.aspx.
I have a visual studio project. I later added a .cs file for testing and have added the appropriate 'using' statements and [Test] and [Testfixture] attributes. When I open the nunit gui application, however, it only accepts .dll, .exe, and .nunit files. I was wondering what exact steps I need to take to execute the tests I wrote. Is it possible to do so directly in visual studio?
You should add the NUnit dll as a reference on your project.
JetBrains' Resharper is able to run the tests inside Visual Studio. Read more about Resharpers unittesting here. JetBrains has also developed a line coverage tool: dotCover.
Right now, Resharper is the best solution.
Test Driven .Net is the best free solution I know of.
Visual Studio 11 will finally allow for 3rd part testing framework plugins.
I am working on a windows as well as web projects. We currently use Visual Studio to build our solution using visual studio 2008.
I would like to move to a more powerful build system such as Nant or MsBuild for atomate.
What are the ways & how i do this?
Currntly we use Visual source safe & mercurial(hg) as source control
How does this all integrate with Source Control?
Help me all the ways..
Thanks!
Last time I checked, NAnt didn't support VS2008 project files properly.
I personally like using NAnt as the general build controller, but delegating to MSBuild for the core "build the code into assemblies" part. This has worked well for me in Protocol Buffers, for example.
I don't know about using either VSS or Hg from NAnt, but I'd be very surprised if there weren't adapters available. Where do you need to integrate source control with the build, is it for version numbers, continuous integration, or something else? You may find that whatever continuous integration server you're using can handle the source control aspect itself, and that your build file doesn't need to know about it.
This really depends on what you want to automate and how. Visual Studio Solution files can be called directly from MSBuild, so to just build the solution without Visual Studio, nothing has to be done.
NAnt can call msbuild to build Solution files for you, so you can wrap you solution build in a NAnt script and do other useful things around it. This is how I usually do things. That way your build script and your solution files stay in sync.
NAnt has had VSS tasks since the dawn of time, so checking out the code is trivial. If they don't have a Mercurial task, there is always the exec task which will allow you to run any commandline program (I assume there is one for Mercurial).
Normally I have a build server with a working copy of the application/solution. Then, each night, the server calls a NAnt script that updates the working copy to the latest revision, and builds the solution using the msbuild task. Then you can do all kinds of nifty things like creating zips or tars, or even installers.