I am trying to automatically open an NDepend Project when the Solution builds in an automated build in TFS2010.
This stems from this previous question. The aforementioned post is where I tried (and failed) to integrate NDepend's code metrics software with an automated Team Build via messing with the XML of my solution.
I decided since I wasn't getting anywhere in messing with the XML, that I would try a different route. In another program I have developed, I used
System.Diagnostics.Process.Start("blah.txt");
to trigger Notepad to run and open the text file "blah.txt."
I figured I could use the same concept to possibly help me with this NDepend integration. So I researched MSDN to see if I can find out more about the Process.Start method. And using this example
Process.Start("IExplore.exe", "C:\\myPath\\myFile.htm");
I substituted in my own paths to what I believe should open the project file "myProj.ndproj" inside the VisualNDepend application like this
System.Diagnostics.Process.Start("C:\\tools\\NDepend\\VisualNDepend","C:\\myProj\\myProj.ndproj");
I may be taking that example and tweaking it out of context, I'm not sure, but it seemed to me that what I tried should work. The solution built fine without any errors, but VisualNDepend didn't run.
It finally hit me that I was trying to use this code that would only execute when the program ran when I really need it to execute when the program builds within TFS and Visual Studio.
I asked my coworkers if they knew of any built-in ways within TFS or VS that would recognize whether or not the solution was being built or not. And they didn't really know of anything in particular. I tried "Googling" this topic and couldn't find any information that was useful to me.
Does anyone know of how to accomplish this? Or am I chasing a lost cause by trying to execute some C# code behind the solution? In which case, is my best bet trying to tweak the XML like I had previously been attempting?
I would recommend writing a custom build task (or tasks). You can essentially make the task do anything you'd like -- run a process, spit out results, etc., and it can be invoked directly from your MSBuild script.
I'm not sure if I'm answering your question (or if I even have a grasp on what you're trying to do), but that's probably the area I'd be looking to find my solution.
Related
In UiPath you can create Custom Activities using C# code as seen here. I dont know much about C# and I was wondering if anyone has any clue how or if its even possible to create a custom activity with Powershell and how I would do that.
Finally, any insight on how I could wrap up the code (and Im assuming corresponding dlls) into a nuGet package would be immensely helpful. Thank you in advance!
I've tried with C#. I got it to work, but as I try to do more complex things, Id like to know if I could leverage powershell as I am much more familiar with it.
The page you linked contains a step-by-step guide. You can't use PowerShell to create custom activities, you will need Visual Studio and C#. There is the free Community Edition available that you can use, but check whether the terms apply.
With VS installed, you would go ahead an create a new class library - just follow their guide.
When your activity is done you would need to deploy it as a NuGet Package, and you can use the Package Explorer to do so. This is were you would "wrap up" all binaries created - they become part of said package.
However, since you mentioned PowerShell - not knowing your precise requirements, of course - there is an activity dedicated to executing PowerShell commands in UiPath: the Invoke PowerShell activity. If you're already familiar with PS, if you have plenty of scripts lying around, just use this activity.
I've spent the last few weeks trying to figure out a way to implement (or find someone who has implemented) regressive testing for our build process, but so far I haven't found anything that works. We use TFS2008 and VS2010, and upgrading to TFS2010 is not an option for us. I've tried to use NDepend to give us the list of changed methods and type dependencies, but running it through our build script has proven supremely unreliable (if I run the same build twice without changing anything I would not be surprised to have one perfect NDepend report, and one exception saying NDepend can't run for one reason or another).
Unfortunately, I'm pretty much stuck with the tools I have (TFS2008, VS2010, MSBuild, and MSTest). I could probably get another tool, but changing the tools I already have (such as moving from MSTest to NUnit, or TFS2008 to TFS2010) will not be possible.
Has anyone does this already? Or can someone point me in the right direction to find which methods and types changed between two builds programmatically?
If you have unit tests and a coverage report. Then you could diff the coverage report before and after. Any changes to the coverage would be shown in that. You could then regression test off that (which I assume is manual)
I have written quite a bit of code of the past few years. I've been using the Visual Studio Development Environment for my C# code, but I wouldn't call myself an advanced user of Visual Studio. I can create projects, create source code, and build/debug the project. I don't use many of the advanced features of the IDE, so perhaps there is a simple way to do what I'd like.
My code is often reused - especially thing like filter tools, custom controls (plots/etc) and some communications code (COM/USB/etc). Every time I create a new project, I end up importing a lot of code that I'll need. This code is copied to the new project directory. If I end up editing that code in some way, I then need to update all of the other versions of that file in my others projects. I'm always having to verify that the code that I am importing is the 'latest and greatest'.
I know it is possible to add code to your project by link, and then you'll update the source file, but I'm curious if there is a better way. My example of a 'better way' is the Allegro Lisp compiler. When you start up Allegro, all of your code is loaded into Allegro, and is instantly available. Then you can start hacking around on anything you'd like, and have access to all of your previous code. When you edit something, and compile it, it is instantly usable in the rest of your projects as well. (Usually even if the program is open!) Perhaps this is something fairly unique to Allegro Lisp?
Are there any ways to do something like this in C#? I'd like to still be able to keep separate projects, but I'd like to share source between them and not have to worry about versions getting out of sync. What does everyone else do when they would like to recycle code?
Thanks,
Giawa
Take some time, work through the code and create different projects, for the likes of filters, plots. Give meaningful namespaces to these assemblies, put the code under source control, use external references to these repos in the source control of your main project, or only import the generated assemblies.
Copying code will lead to errors due to not correcting an error in one place, but correcting it another. Use source control, it's gold.
I'm a newbie to SSIS / C# (I'm generally a Java developer) so apologies if this is a really stupid question.
Essentially the problem is this: I have two Data Flow tasks which load data up and export them to a legacy flat file format. The formatting is done by a Script Task (C#).
What I'd like to do is share some common code between the two. e.g. I could create a common base class and then extend it for my two different script tasks.
However it seems that SSIS doesn't really make provision for this.
Does anyone know if there is a way of accomplishing what I want to do?
You're correct that there is not a straightforward way to do this directly from SSIS.
In a recent project, we took two different approaches, which both worked fairly well depending on what you need to do:
Create a utility class (as a simple class library) and reference it from your script tasks. This is done pretty much the same as any other sort of reference. If you use .NET 3.5, remember that you'll have to update the version manually in the script tasks since SSIS defaults to 2.0. We also found that if we wanted some manner of reusability in the utility assembly (not relying on hardcoded variable names, etc.) then the package still had to have a fairly large amount of "setup" boilerplate to use the utility scripts.
Create a custom data flow component. This is a much more involved process, but ultimately will do the best in terms of avoiding code duplication. Generally, coding the actual data flow is fairly simple and not that much different than a script component, but the various setup code you'll need can tend to make things complicated. There's also not a lot of support in SSIS for when something goes wrong. Led to a lot of detective work on our project.
If you plan on using something a whole lot, and are committed to getting rid of boilerplate code as much as possible, 2 is the preferred option. If it's being used a few places here and there, consider the simple approach of 1.
I am pretty sure it's possible to access .NET assemblies in SSIS scripts. So you could do it this way. See the article "Accessing .NET assemblies with SSIS" on SQL Server Central.
I believe you will have to create an assembly or webservice for this to work.
This does not completely solve your issue but it does help in not having to recreate all the classes every time you need them (I also do not want to deploy referenced assemblies for my current project ). Firstly you need a master copy of your classes, you can copy them from an existing Script Task using the same process below but in reverse.
Open the Editor for the Script Task and on the Property Explorer click on the Project File (the st_[Guid] ), in the Properties window you’ll see the Project Folder location. (This location gets recreated every time you edit the script task)
In explorer, copy your classes to this folder
On the Project Explorer, click on the “Show All Files” icon
Right click on your files and add to Project
Probably way too late to answer this, but you can click on the solution and add a class there. Then when you go into your scripts you can say add existing object and search for that class you created earlier. For me it was located by the solution for the project. Haven't gone through the deployment or anything for this, but at least you can access the class through the individual scripts.
I've previously asked a question about an issue I have been experiencing with CSharpOptParse that didn't get much of a response. Since I haven't been able to resolve the issue, I'm looking around for an alternative library.
While the issue I'm experiencing isn't really enough of a compulsion for me to search for an alternative...the fact that the last development for this library was done in 2005 worries me a bit.
Does anyone know of any good equivalent C# command line option parsing library?
Mono distribute a library in the form of a single source file to simply place inline in your own projects called Mono.Options since 2.2 as the suggested replacement for Mono.GetOptions
This is basically NDesk.Options and it works just fine in MS.Net too.
CodePlex has a variety of libraries (of varying levels of development) active ones include:
ConsoleFX
commandline
CmdLine
CommandLineHelper