All I'm trying to accomplish right now is get my custom component to show up in the SSIS Toolbox. I've been looking everywhere I can think of for any information about creating a custom Data Flow Component in Visual Studio 2019. I have found plenty of out-dated examples and solved problems, none of which help me solve my problem.
Based on Microsoft's description of how to do this, you would think all you have to do is follow their instructions and it'll work. Not so, at least not for me yet.
Here's what I've done so far in an attempt to simplify and get anything to work:
I Created a class library and referenced the following assemblies:
Microsoft.SqlServer.DTSPipelineWrap
Microsoft.SQLServer.DTSRuntimeWrap
Microsoft.SQLServer.ManagedDTS
Microsoft.SqlServer.PiplineHost
Inherited from PipelineComponent and added the DtsPipelineComponent attribute.
Overridden methods (code below)
Signed the assembly
Created Post-build events to install into the GAC and copied the assembly to the C:\Program Files\Microsoft SQL Server\130\DTS\PipelineComponents folder.
In an SSIS project, I do a refresh on SSIS Toolbox and my component does not show up. I've tried Browsing to the assembly by going to Tools >> Choose Toolbox Items and selecting the assembly.
I get this message:
Here is my simplified code that does nothing: Sorry about having posted it using an image, but using the recommended code highlighters don't work for me either.
Here is a screenshot of the GAC listing:
I must be missing something.
Any help or ideas would be greatly appreciated. If I can't get this to work, I'll have to punt and resort to a Script Component transformation. Really hate to do that as that means each developer will have to maintain a lot of extra code.
Thank you in advance.
Hazy recollection but I'll give it a go.
The installation to the GAC means that when the package runs, the execution engine will be able to find the required assemblies and do the code instructions.
Design-time needs the assemblies elsewhere because...reasons. With 2005/2008, you had to manually add items to the "SSIS Toolbox." You are attempting to add items to the "Toolbox" which is a confusingly similar name but it's not SSIS. SSIS Toolbox is populated only when a package is opened and the project type is SSIS.
Visual Studio now automagically picks up components but either way, the assemblies need to be sitting in the targeted version Microsoft SQL Server XXX DTS assembly-domain folder.
Assume I build a dataflow component with bindings for SQL Server 2017. I would therefore install to
C:\Program Files\Microsoft SQL Server\140\DTS\PipelineComponents
If you built a custom task, it'd go to
....\DTS\Tasks
On a 64-bit machine, copy the component dll to the C:\Program Files (x86)\Sql Server\Dts<appropriate version>\PipelineComponent\ folder
That's going to require admin rights but you already needed them for GAC'ing the assembly as well.
This Red-Gate article seems to confirm what I'm saying as well. Developing a Custom SSIS Source Component
If you've got smart developers, you might also take a look at using Biml to create your SSIS packages. With it, you can have a single Script Task/Component defined for the common project and whenever you emit the Biml into SSIS packages, they all use the same common core bit of logic. No subtle copy/paste inheritance like you can run into if you don't go custom component route. Or you use a declarative framework for describing your packages, aka Biml.
Related
I am currently trying to automate our .NET builds and have currently run into a snag. When building the project in Visual Studio on a machine with a InstallShield 2016 Professional License, everything builds fine. However, when trying to use MSBuild to build the VS Solution on a machine with InstallShield 2016 Standalone, the resulting MSI does not have a required DLL or a Custom Action. Meanwhile, trying to build the .ism using Iscmdbld results in the inability to find the Primary Output of the csproj's, Even after building in Devenv
If you are using project output groups (like Primary Output), your choices are limited. You have to use either the VS integrated build (via devenv), or MSBuild; iscmdbld is unable to resolve project output groups.
Your other alternative is to change from project output groups to using static (or dynamic) file links that don't require Visual Studio's knowledge. I tend to prefer static links, as it's easy to tell exactly what's in the project. More importantly, with static links you can't silently lose files that you'd previously added, thus it's easier to avoid potentially breaking component or upgrade rules.
Hopefully, this isn't too old to be of use. InstallShield is the absolute worst, I know.
If you edit your .isproj in a plain-text editor, you'll see that it's just a regular MSBuild script. You'll see that there is a lot of commented out stuff that explains (poorly) things you can add to it. Find the ItemGroup that contains the explanation about "ProjectReference items" and add a node of the following form:
<!-- The ProjectReference items refer to any Visual Studio solutions you want to automatically probe for Project Output Groups. -->
<ProjectReference Include="..\Path\To\Your\Proj.csproj">
<Project>{2d3f37cc-0e93-4673-a3df-59c556185f71}</Project>
<Name>Name Of Project As It Appears in VS</Name>
</ProjectReference>
After adding the above to all of my .isproj files, my automated build worked fine. Why the idiots at InstallShield never saw fit to add this capability to the UI, I'll never understand.
Unfortunately, I don't have any answer to the Custom Action problem, if it's not related to the above.
I created a basic install for my VSTO Excel plug-in by publishing my project.
It pretty much worked ok except for some reason it missed 2 dependencies, dll's which are needed to communicate with our SAP system.
Did loads of Googling but I can't find a way to add them in Visual Studio.
I tried downloading the setup project type from MSDN, but wierdly when I built the install it included the SAP dll's but it didn't install my plug-in! There doesn't seem to be much info on how to do this with VSTO, or at least I couldn't find it.
However I note from MSDN that there are a lot of problems with that template, so it's possible it doesn't work for VSTO stuff.
So, a workaround is obviously to run both - and that works ok - but it isn't ideal and (understandably) not satisfactory for our support team.
I would think there are several ways to fix this problem, so if anyone could answer one or two of the following that would really help!
How can I make sure that my dependency files are included in my setup when I use Publish?
What is the correct way to create a Visual Studio 2013 Installer Project
that works correctly with VSTO?
This looks like an answer to question 2:
https://msdn.microsoft.com/en-us/library/ff937654.aspx
1.How can I make sure that my dependency files are included in my setup when I use Publish?
You need to add them as a content to the target folder or make sure that files are copied to the output folder with the add-in assembly. Right click on the reference in the Solution Explorer window and see the reference's Properties. Pay special attention to the Build Action, copy to the output folder properties and etc.
2.What is the correct way to create a Visual Studio 2013 Installer Project that works correctly with VSTO?
The Deploying an Office Solution by Using Windows Installer article describes all the required steps for deploying Office add-ins.
I keep running into an issue with our TFS build server. I've got 2 projects (both in the same solution), 1 is a WebForms project, running .Net 4.0. The second is an ASP .Net MVC5 project running .Net 4.5. There is also a Silverlight project, but the problem is reproducible with just the first two.
Both of these projects use NuGet packages for various libraries. Sometimes there are different assemblies within a package for their respective environments. A .Net 4.0, 4.5, SL assembly, etc.
The build server seems to dump all of the libraries required into a single folder, then pulls from that to build the solution. This causes problems in many cases, with the wrong project getting the wrong assembly version. This does not occur locally, only on the build server. I can't figure out what I need to do to keep this from happening. Any ideas?
Yes, I hate this standard behavior, but TFS will output everything to the same folder by default, and then you will get various errors depending on which order msbuild compiles your projects if you have references with the same name or even project outputs with the same name.
The easiest workaround is to use the AsConfigured option on the Process tab, '2. Build' -> 'Output location' of the build definition window. This keeps your normal source structure intact, but I think you will lose support for automatically dropped outputs (i.e. you will have to provide a script to do that yourself). If you are only using TFS Build for validation, this is the cleanest approach.
You can also use the PerProject setting and split up your projects into two distinct solutions, perhaps suffixed by platform (we've done that numerous times in our company). Then, you specify both solutions to the build process and it will create two separate folders in the output, one for each solution.
This is all assuming you are using TFS 2013. In TFS2012, there is a similar option but it is in '3. Advanced' -> 'Solution Specific Build Outputs'. You will probably have to go this route if you are using TFS2012 or you will need to modify the default workflow yourself to add your own logic.
EDIT:
From your comment to the other poster I see you are using TFS 2010. Well... I think this was absolutely not supported at that time, I remember having similar problems, but we upgraded to TFS 2012 and all was well.
I think your only option is to either create two separate build definitions and build each solution that way, or you will need to checkout the xaml workflow and edit it with your own logic. Perhaps downloading the TFS2012 template and "porting" it to TFS2010 would be a better approach since at least you would not be reinventing the wheel that way.
Explicitly setting dependency in VS2010 between unmanaged C++ project and C# project is honored in VS2010, but dependency is ignored in MSBuild 4.0.
It is impossible to add a reference to unmanaged C++ project from C# project, afaik.
How do i ensure correct build order if a solution contains unmanaged and managed projects?
MSBuild has a bug in it and doesn't correctly honor project dependencies added at the solution level. Take a look at http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/80cc6447-b720-4806-8395-7c257b207613/ and https://connect.microsoft.com/VisualStudio/feedback/details/613284/msbuild-4-does-not-respect-build-order-when-building-a-solution
A posting by Microsoft on the connect page indicates that its a bug in the 64-bit version of MSBuild. Try switching to the 32-bit version to see if that solves the problem.
If you can't do that, or it doesn't work, there are two other options. Neither of them are ideal.
The first option would be to manually edit the SLN file and change the order the projects appear in the file to match the build order you want. I imagine Victor's solution would be a much better idea, since additional changes to the solution file could end up overwriting the changes again.
The second option would be to manually export the MSBuild "metaproject" for the solution and edit the build order directly and add any other customizations you need. From what I've read, even at Microsoft they don't "dogfood" solution compilation - instead, they avoid them completely during builds and use custom MSBuild files instead.
To generate the metaproj, set the environment variable MSBuildEmitSolution to 1. After running MSBuild on the solution and you should see a ".metaproj" file in the same directory - it contains the script that MSBuild generates in-memory to compile the solution. You should be able to make the necessary edits, check it in, then set the build server to compile it.
The issue will disappear in the next release of Visual Studio. The Microsoft Connect page has a posting from Microsoft that it will be fixed in the next release, and rumor has it they're getting rid of .sln files and replacing them with proper MSBuild projects.
We found a bug in Web Service Software Factory a description can be found here. There has been no updates on it so we decided to download the code and fix it ourself. Very simple bug and we patched it with maybe 3 lines of code. However* we have now tried to repackage it and use it and are finding that this is seemingly an impossible process.
Can someone please explain to me the process of PLKs? I have read all about them but still don't understand what is really required to distribute a VS package.
I was able to get it to load and run using a PLK obtained from here, but i am assuming that you have to be a partner to get a functional PLK that will be recognized on other peoples systems?
Every time i try and install this on a different computer I get a "Package Load Failure". Is the reason I am getting errors because I am not using a partner key? Is there any other way around this? For instance is there any way we can have an "internal" VS package that we can distribute?
Edit
Files I had to change to get it to work.
First run devenv PostInstall.proj
Generate your plks and replace ##Package PLK## (.resx files)
--Just note that package version is not the class name but is "Web Service Software Factory: Modeling Edition"
-- And you need to remove the new lines from the key
ProductDefinitionRegistryFragment.wxi line 1252(update version to whatever version you used in plk)
Uncomment all // [VSShell::ProvideLoadKey("Standard", Constant in .tt files.
The short answer is no, you don't need to be a VSIP partner registered with Microsoft to obtain and use a PLK. The PLK you obtained from the site should work on any VS install. (On a related note, Microsoft has eliminated the requirement for PLK's altogether for VS 2010.)
The following pages should help with debugging what the issue is:
http://msdn.microsoft.com/en-us/library/bb164677.aspx
http://blogs.msdn.com/dr._ex/archive/2006/12/14/debugging-package-load-failures.aspx
There is also a tool in the Visual Studio 2008 SDK called the Package Load Analyzer that should help you debug the load failure (and confirm that it's actually a PLK issue and not something else). Copy and run VSSDK_PLA.exe (under VisualStudioIntegration\Tools\Bin under the VS SDK install location) to your test machine to install the Package Load Analyzer tool.
You don't have to worry about package load keys when rebuilding the Web Service Software Factory because it is a guidance package that depends on GAX, which has the only PLK needed. To build guidance packages, like the Service Factory, you also need to have GAT installed.
The Service Factory source should contain the setup projects you need to build and redeploy it. If you have an issue, the discussion forums on its community site (http://servicefactory.codeplex.com) are monitored by team members. Response is pretty good.
Aaron is right that this whole story gets a LOT easier in VS2010. VSIX is pretty sweet. We are updating the Service Factory to VS2010. It should be ready for release within a month.
Don
MS p&p