I am adding this custom build task to my TFS 2010 build workflow, however when attempting to add it (ColinsALMCorner.CustomBuildTasks.dll) to the toolbox, I get error:
'Could not load file or assembly file 'ColinsALMCorner.CustomBuildTasks.dll' or one of its dependencies. Operation is not supported'.
I have added all of its dependencies to (I admit, this is probably redundant):
1) the same location where the ColinsALMCorner.CustomBuildTasks.dll resides, which is ..\BuildProcessTemplates\CustomActivities
2) in the Public Assemblies folder: Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies
And I have the build definition xaml file correctly importing the ColinsALMCorner.CustomBuildTasks namespace
Although the activity is set to target .Net 4.5, the documentation says that TFS 2010 / .Net 4.0 is supported, so I assume this should all be possible.
My Questions:
Is this possible with TFS 2010 / .Net 4.0 development environment? My concern is that the error message isn't telling the real story, for example maybe it is able to find it, however just not the right version of the assembly.
Is it likely that since the DLL targets .Net 4.5 I need to have all of its referenced dll's also be the 4.5 version? For example, it references Microsoft.TeamFoundation.VersionControl.Client however I only have the version 10.0.0.0 (which I assume the .Net 4.5 version of this might be 11.0.0.0)
Here was the solution, in short story format: I installed Visual Studio 2012. Result: I was able to add ColinsALMCorner.CustomBuildTasks to my workflow in Visual Studio 2010 without error. I assume this means there was a 2012 (v11.0.0.0) DLL or two required to use the activity in 2010, despite the fact that the requirements state:
Team Foundation Build 2010, 2012 or 2013
Related
I ran Dependency Walker on an assembly (.exe) after compiling in Debug (Any CPU) and it seems like there are older core and kernel issues. The entire code is VB.NET 2010, so I am wondering why VS2017 Pro didn't clean those out?
Something interesting was that the Conversion to a new VS version did not occur, for which errors are shown -- it just showed the forms, modules, etc. as if there were no errors.
Should I try a Reload or something?
The errors were caused by having old references or assembly libraries which called DLLs (like VBIDE.dll and MSCORE.DLL) in the applications folder. There were very old references, some of which were to VB6.
Recall, remember that Visual Studio has always been dropping certain Windows forms controls over VB 2005, VB 2008, VB2010, etc. so you need to make sure those older controls are not in forms when you upgrade to e.g. VS 2017.
When I publish .net core application in Visual Studio 2017 RC, it creates 2 unwanted dll's, which are as follows:
Microsoft.DiaSymReader.Native.amd64.dll
Microsoft.DiaSymReader.Native.x86.dll
It happens only in Visual Studio 2017 RC and not in Visual Studio Express 2015.
I have found following link on github, but fix mentioned over there only removes ref folder from publish output.
https://github.com/aspnet/websdk/issues/123
Is there any way, by which I can get rid of these 2 heavy dll's as they size around 2MB in total?
This was caused by a bug in Microsoft.NETCore.App version=1.1.0. When you reference that version, implicitly (the default), or explicitly, you will get those two assemblies in your publish directory.
The fix is to either upgrade to Visual Studio 2017 RTM, which implicitly references the version with the fix (1.1.1), or to explicitly reference 1.1.1 by adding <RuntimeFrameworkVersion>1.1.1</RuntimeFrameworkVersion> to your .csproj.
I have the dreaded issue from my attempted installation of an MSI:
MSI (c) (98:B0) [18:01:22:818]: Invoking remote custom action. DLL: C:\DOCUME~1\sspencer\LOCALS~1\Temp\1\MSI19.tmp, Entrypoint: CheckFX
MSI (c) (98:FC) [18:01:22:833]: Cloaking enabled.
MSI (c) (98:FC) [18:01:22:833]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (98:FC) [18:01:22:833]: Connected to service for CA interface.
Action ended 18:01:22: DIRCA_CheckFX. Return value 3.
After quite a bit of digging, this is actually indicating that the DLL failed to load outright, the CA server was unable to connect and start hitting the DLL entry points.
I used orca and 7zip to extract the custom action for the DIRCA_CheckFX which is inserted by Visual studio when the deployment project builds. I grabbed the DLL and then executed Dependency Walker in the host system (Server 2003 R2) which gave the error:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
I recompiled the system using the VS 2010 compiler, extracted the DLL and ran dependency walker on it, which did not create the same error. I.e VS 2010 compilation works, VS 2013 compilation fails as the included DLL won't load in the target environment.
My question is how do I troubleshoot which DLL(s) are missing in order to troubleshoot that error reported by Dependency Walker.
Must be installed VS 2010 from which you can get the valid file "dpca.dll".
Close Visual Studio 2013
Copy file with replace dpca.dll from
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\Deployment to C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\VSI\bin.
Open Project
Rebuild
The preview of the .vdproj resurrection uses DLLs that don't support Windows XP or Server 2003. Microsoft posted an update that might have fixed that bug.
Here's what I did to workaround this issue for a 32-bit deployment project.
Build the setup project in VS2010 once. This package is not dogged by the issue but I didn't want to have to keep building in a different VS version.
Open the resulting msi with Orca, select the Binary table and export the content of MSVBDPCADLL to a file.
Now after you build it in VS2013 use Orca to import the exported data into Binary\MSVBDPCADLL to fix the package.
I have to do a similar thing with the 64-bit project but in this case it's to import the correct InstallUtil binary (being C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtilLib.dll).
Visual Studio deployment projects were so horrible that Microsoft removed them from Visual Studio 2012. Developers were so ignorant as to why they were horrible that they begged and begged for them to come back. The smart guys at Microsoft who understand MSI left the building and the people remaining caved to the developers asking for it to come back.
One of those really smart guys summed it up perfectly in a tweet:
The return of vdproj: Headshots, people, or they come back as walkers.
I wrote an article on my feelings: Visual Studio Installer Resurrection
So let's talk about the way the tool is failing you this time. Take a moment to read this article written by one of the other really smart ones to leave MSFT:
Zataoca: Custom actions are (generally) an admission of failure.
VDRPOJ created a custom action to do something MSI could have done natively and now it's failing. So let's say you find the DLL and fix it to work on your machine. What happens when you ship your MSI to 1,000,000 machines? How many machines will it fail out there? How many support calls will you get? How many tweets will you get that your product sucks?
Simply put, I'd redo your installer using a better tool such as Windows Installer XML and Industrial Strength Windows Installer XML. If you have the money to spend InstallShield Professional is a good choice also.
I got a copy of a Visual Studio 2005 project from a friend. The project referenced the DLLs Microsoft.ReportViewer.Common and Microsoft.ReportViewer.WinForms. On my machine I have Visual Studio 2012. I upgraded the project. The references to these DLLs are broken, understandably, because they are Windows locations, not in the VS project. So, I want to delete the references and re-create, but I cannot find the DLLs on my machine. Do they not get installed with Visual Studio 2012? Can I download them?
I got a copy of a Visual Studio 2005 project from a friend
Which explains the problem, the target .NET version of your project is 2.0. The ReportViewer included with VS2012 requires at least 3.5.
Fix it with Project + Properties, Application tab, Target Framework combobox. You'll then find the ReportViewer control back under the "Reporting" header in the toolbox.
These have been replaced by Report Server. Though if you'd copy them over from your VS2005 machine you should still be able to use them as binary references in your solution. You can download the binaries from the MSDN Download site.
Though there should be binaries for Visual Studio 2012 as well. I suspect they will get installed when you install the SQL Server Development tools, which include the SQL Server Reporting Server components.
You can try to use the Redistributable package for Visual Studio 2010.
I developed the project in visual studio 2010. That exe file is not supported for other PC's.
which dotnetframework to be installed? other than dotnetframework is there any other requirements needed?
Are you sure it's not the CPU type you specified during compiling (x86 vs x64 CPU). If you compiled in 64-bit and a user only has a 32-bit processor (x86), your code won't run.
The .Net Framework should work on any PC-based system, but be sure to include it in your deployment or setup package. (you can provide Excel, .NET Framework, and many other packages with your package.)
You should also try to find out what error messages your users are receiving -- which will point you in the right direction.