I've created a SSIS Custom Task in C# and I'm currently developing the UI. I was wondering if there is a better way of debugging the UI instead of compiling the project, copying the DLL's into the appropriate DTS folder and then opening the test Package within BIDS and then attaching the process to Visual Studio. This part I'm not bothered about but once you've tested the UI and made changes to UI within Visual Studio. I've got to recomplile the DLL's and then repeat the entire process. I've got to close BIDS and VS because they don't release the DLL's before I have to start the entire process over again. Does anyone have any tips to speed up this process. It's just so frustrating having to do this everytime.
Sorry, but that's the only way Microsoft has devised. If you are repeating this process over and over again, I would suggest creating a batch file for all the operations so that instead of doing 5 steps over and over again you just fire the batch file and be done with it.
I thought I would add this. The best way I've found of debugging SSIS components is to:
In the Project Properties under build set the OUTPUT path to the correct SQL Server DTS sub folder and then in Build under the Post Build events put:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\gacutil" -u "C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Tasks\$(TargetFileName)"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\gacutil" /if "$(TargetPath)"
Uninstall the assembly using the gac and then resinstall it. The reason I'm uninstalling it is because I was having a lot of trouble with BIDS not referencing the newly inserted DLL. Even restarting my computer it kept referring to the older DLL. I guess is that it had cached it. I'm also using this for developing components for BIDS 2012. I am aware that you don't have to sign or register components with the gac for BIDS 2012 but BIDS was having problems referring to the newly created dll's. By doing this I dont have to close BIDS everytime or delete and readd the component to the design screen.
You would think there was a simpler version.
You may want to read the blogpost by Matthew Roche here. Its quite informative and gives you a better way of doing things.
Related
I keep getting this error during the publishing of my VS 2019 C# win forms project
Unable to copy file "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.TextManager.Interop.8.0.dll" to "bin\Debug\app.publish\Application Files\Database Client_2_0_0_47\Microsoft.VisualStudio.TextManager.Interop.8.0.dll". Could not find a part of the path 'bin\Debug\app.publish\Application Files\Database Client_2_0_0_47\Microsoft.VisualStudio.TextManager.Interop.8.0.dll'. Database Client
This also happens with 4 other DLL's with some being from VS 2019 itself and some from NuGet packages
This has only started happening recently so I'm unsure whether this is an issue with VS 2019 as no fundamental code has been changed and the only thing that has is some logos on a few .rdlc documents (Microsoft Report Viewer).
I'm running VS 2019 Community on version 16.11.4 with only .Net Desktop development, Office/Sharepoint development and a few individual packages installed.
I've looked around and can only seem to find people having issues with the .exes themselves due to them still being open however this is not the case for me as I have checked and there are no background processes like devenv.
What's strange is both the Debug and Release build fine with no issues whatsoever.
I've also tried deleting the \bin and \obj folders to no avail.
Below are some images of my settings that involve publishing
Publishing Main Settings
Prerequisites
Deployment
It seems the solution to this problem, as #HansPassant commented, was to shorten the build path as it was exceeding the MAX_PATH variable.
Once my project was moved from the default C:\Users\Drew\source\repos\ to just the C:\ drive my project was able to publish successfully.
When I build a C# program (this has been going on for several different solutions/projects I have been working on) in Visual Studio 2017, the new, updated code will build and run in debug mode (and run correctly).
However, the application that Visual Studio has been outputting when I build/debug them has been remaining with the original, first version of code that I saved. When I choose the options to rebuild, it will update the time stamp on the application and .pdb files, but the application will perform the way it did in earlier code versions, not the most recent code version that was running problem when I ran debug mode immediately after pressing Ctrl + F5.
These are C# Console Apps with the .NET Framework 4.6.1, if that makes any difference. I checked the output folder, and it is indeed the desired folder and the one I have been looking in... so why is the time stamp updating on the application (.exe file) that it outputs, but not the code itself? What am I missing?
When I run into strange things like this in Visual Studio, the first thing that usually works is to clean the project and rebuild. If that doesn't work, I'll close Visual Studio, re-launch, then clean and rebuild again. If that doesn't work, I would start looking into any extensions you have installed that might be getting in the way of your build process.
Further, you can look into logging the extensions activity to help troubleshoot if there are issue there. See the following article:
https://blogs.msdn.microsoft.com/visualstudio/2010/02/24/troubleshooting-extensions-with-the-activity-log/
You may have already tried this, but since it wasn't mentioned I thought I'd provide it for others in a similar situation.
Two possible reasons:
(1) Your project was not recompiled during debugging. Please enable Edit and Continue under TOOLS->Options->Debugging.
(2) Visual Studio has a concept of incremental build. If you have a solution with two or much more projects and if you change source code in only one of the two projects, the "Build" command will compile only the modified project. But the "Rebuild" command, on the other hand, it will recompile all projects in this solution.
I came here just to find a solution to debug such kind of problem but no satisfying answer yet.
The original content as below:
The program I wrote in c# and WPF in VS 2013 is packaged by Installshield LE 2013, and there is no error during the package procedure. Then I ran the Setup.exe to install the program and there's nothing wrong either. However, after I run the program installed, nothing happened, neither error message reports nor visible windows, even I didn't find any process concerned in the task manager.
I can't figure out where the problem is, for there's no error or clue to analyze and investigate. Maybe something I missed when adding application files, I guess.
By the way, I used Sqlite as database and packaged the data file under the bin directory, is it one of the reasons?
I haven't used install shield but setup project can be an alternative solution to your problem.
Here is a link that explains step by step procedure of creating a setup project and .msi file afterwards. Have a look.
http://www.c-/UploadFile/dpatra/create-setup-and-deployment-of-wpf-application-step-by-step/
I've solved the problem.
It's not about InstallShield. It's about dependencies. There're two .dll files I didn't packaged, which resulted in the errors in running this program.
So I do the debugging by removing the files under Debug directory to judge which file is necessary to run this program. Maybe it's not a good way to solve such problem but for me, it worked after all.
I'm trying to install a custom test adapter via NuGet, but it seems like VS isn't recognizing it. I've looked through the code in Microsoft.VisualStudio.TestWindow.VsAdapters.UnitTestExtensionDiscoverer, so I've realized the dll has to end with *.TestAdapter.dll. Using that name makes vstest.console work for me when I specify /TestAdapterPath, so I'm not sure why the VS2013 test window isn't showing my tests.
The adapter does work when installed by copying the relevant files to C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\Extensions.
Are there any other path or filename conventions I need to follow for VS2013 to load my test adapter? Without any logging or error messages I'm really not sure how to gather more information to debug this.
The issue seems to have been that I was trying to debug by overwriting my dlls in the packages directory. This doesn't work because VS copies your package directory to something like:
%TEMP%\VisualStudioTestExplorerExtensions\My.TestAdapter.1.0.0.23
essentially caching it with the key being the version number. If you copy the file into the project packages directory VS won't copy it because the folder number didn't change. So, to update your extension you have to keep publishing NuGet packages.
At least that's how I understand it.
Edit: I've also noticed that when you upgrade your test adapter through NuGet, it won't start using the new version until you restart VS, or kill vstest.*
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.