We are in the process of upgrading our SQL server from 2008 to 2014 and separating the Database server from the file server. I changed my SSIS packages to have project parameters defined, which means that... when I deploy my project all 35 packages within my project get deployed. I would rather have the smallest unit of deployment to be the package. Should I revert back to the package deployment model and get rid of my project parameters? I fail to understand how two developers can work on two packages from the same project and only the 'tested' one needs to be deployed.
Any insight to help me understand would be helpful.
Thank you much..
SD
With the release of SQL Server 2016 and SSDT 2015 the issue of single package deployment is now a thing of the past. There is the new Deploy Package option (VS 2015) that comes up for deploying individual packages within a project deployment model.
Source -
http://www.sqlshack.com/single-package-deployment-in-sql-server-integration-services-2016/
Where as I know there are few differences in Project and package deployment.
Project uses parameters while Package uses Configurations files/tables.
Project is located in an .ispac file and packages have .dtsx extensions whilePackages have .dtsx extensions.
Project is deployed to integration service catalog while Packages are deployed to the MSDB or File.
New environments in the SSIS catalog can be used with parameters while System environment variables can be used with configuration.
Related
In my newly created BizTalk 2020 Dev environment when I'm adding a BizTalk Server Application Project (.btaproj) to the solution, the dialog window where you set the name of the project is showing the .NET framework selector and it defaults to version 4.7.2 as expected.
However when the project is added to the solution I can see in the properties for the project that it is targeting .NET 4.6.1. Has anyone seen this? is it a bug or something wrong with installation?
Naturally I change it to version 4.7.2 as the regular BizTalk project and everything compiles fine in Visual Studio.
But on our build server the same project fails. We use Azure Devops for CICD.On the build server we have the same version of VS installed (2019 enterprise) and BizTalk Server Extention (v3.12.1.0) is installed as well as msbuild tools from BizTalk server installation.
In the logs I first get a Warning:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3274: The primary reference "A.dll" could not be resolved because it was built against the ".NETFramework,Version=v4.7.2" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.6.1". [B.btaproj]*
And further down in the log the btaproj will not find the assemblies to include in the .zip package.
Message above implies that I have different target versions but I don't.
Now the strange thing is that I can log on to the build server and clone the same project and compile it with VS just fine.
The only way to make the build server compile the project successfully (or any other BizTalk project with .btaproj for that matter) is to change .NET to 4.6.1 (for both .btproj and .btaproj) and it all compiles nicely and deploys to BizTalk environment.
I have checked project files and files checked in to Git and everything seems OK with the sources files. The clean flag I set to clean sources and output directory. I Can compile a regular BizTalk project and .NET application with 4.7.2 on build server just fine it's only when I involve a .btaproj project where it starts to misbehave.
Can anyone point out where to start to look? the .btaproj seems fishy to begin with but it can also be isolated to the msbuild on build server and it differs from compiling with Visual Studio.
Since the BizTalk Server Application project e.g .btaproj defaults to target framework moniker 4.6.1 when added to the solution you will need to manually change the version manually for BOTH debug and release.
Do not get misled by the create project dialog where it defaults to version 4.7.2
As a workaround ,you can specify /p:TargetFrameworkVersion=v4.7.2 in the MSBuild Arguments column of the MSBuild task.
MSBuild lets you set properties on the command line by using the -property (or -p) switch. These global property values override property values that are set in the project file. This includes environment properties, but does not include reserved properties, which cannot be changed.
For details ,please refer to this document.
I followed this blog post and I expected Nuget to just work. It obviously has not. I get errors on all of my third party dll's that I expect NuGet to update automatically:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\
Microsoft.WebApplication.targets (182): Could not copy the file "bin\AutoMapper.dll"
because it was not found.
I have set everything up correctly and I have ensured that the solution has Package restore enabled. If I delete a package locally and build, NuGet restores that package for me.
I am not sure why it is not fuctioning on the build server though.
Any Suggestions?
Try to add NugetRestore Activity to the TFS workfolw
Note:
For Team Foundation Build 2013 on-premises and Visual Studio Team Services (formerly Team Foundation Service), the default Build Process Templates already implement the NuGet Package Restore workflow without any special configuration.
I came across a similar error for log4net nuget package and I solved it in a different way. May be this will be useful to someone some day.
The error from TFS Team Build 2015
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications\
Microsoft.WebApplication.targets (182): Could not copy the file "bin\Log4net.dll"
because it was not found.
Cause
The path to the nuget package in the .csproj file for referencing the package in the project cannot be found
Resolution
Edit the .csproj file of the project that has the error.
Look for the node ItemGroupin the .csproj file
You will see the HintPath pointing to a folder, most like the folder contain the name of solution as where it will file the DLL.
Replace the HintPath with <HintPath>..\..\Assemblies\3rd party\log4net\1.2.10.0\2.0\log4net.dll</HintPath>
You nuget package library may not be log4net but a different library. A very easy way would be to be edit the .csproj file of a project in the solution that contains the same nuget package library, copy the reference of the nuget in the ItemGroup and replace in the project that has the error. The reference should start contain ...\Assemblies\3rd party\ ... instead of a physical file location on your machine
I am looking to build projects on a build server (right now it is just a server but I want to use MSBuild to build projects on there). I want to use PowerShell scripts to get my code from a repository (Doesn't matter what type), put the source into a common directory, put all dependencies into a common directory (similar to how it is build in my workspace on my local machine), build everything and put all the deployable binaries into a bin which I will be moving to the deployment directories using other Powershell scripts.
I assume I am going to have to have MSBuild installed on the server that I will doing all of this on. Do I need to have the .Net framework installed on that server to accomplish this? Do I just need the EXE to have this work? Is there a good way to managed dependencies? Should I have them in a specific folder?
A lot of the core .NET assemblies are stored in the Windows Global Assembly Cache (GAC). You won't have to worry about those. Yes, you'll need the Microsoft .NET Framework installed, in order to compile (build) .NET projects. I believe msbuild.exe is included with the .NET Framework, so you'll find it under a location such as: C:\windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe.
Your PowerShell script will have to copy any external dependencies (assemblies (DLLs and EXEs), .NET resource files, image files, external binaries, etc.) to the appropriate target location after compilation, such that the software executes successfully. You'll need to work with your software development team to determine [comprehensively] what those dependencies are.
MsBuild.exe moved, and is now part of Visual Studio as of v2013.
To get the latest version of MsBuild.exe without having to install Visual Studio 2013, download Microsoft Build Tools 2013
How to build and deploy process from Eclipse to jbpm6 console? When I right click on JBPM6 project or BPMN process definition, there is no option of deploying.
Is there an ant script to generate deployable process archive from an eclipse jbpm6 project?
When I ask about Guvnor, people say its removed from Jbpm 6. Where do my deployment go then?
Is there a documentation about the structure of deployment file? Can I deploy my own web services/rest services/EJBs along with JBPM process?
Camunda has a very well documented process deployment model. I am expecting similar model from JBPM6, but there is very little documentation.
http://www.bpm-guide.de/2011/09/28/less-code-bpm-with-camunda-fox-server-activiti-and-jboss-as-7/
There was a huge change in technology in the project for the 6 release, so you need to wait until the final community version is out. Now guvnor was replaced by a different more up to date repository where now all your deployments go. The structure of a deployable artifact is a regular maven project, which make your life easier when you need to deal with dependencies between packages.
Please check the following URL to see the changes in the infrastructure:
http://blog.athico.com/2013/06/goodbye-guvnor-hello-drools-workbench.html
I have recently started to build manifest files for the ETL packages by navigating to the project properties and setting the Create Deployment Utility to true. I was using batch files before this to deploy the packages, but can't run them anymore because I don't have enough permissions on the server after a new system roll-out.
The problem is that in some cases, I only need to deploy a couple of ETL packages instead of all of the packages under the project. When the project is built, the manifest file lists all the packages under the project that may or may not be required for deployment.
Is there any way for me to only include a couple of ETL packages in the manifest file instead of every package under the project?
According to MSDN, the possible option seems to be adding the necessary packages that should be deployed to a different SSIS project and use the deployment utility on that project.
Redeployment of Packages
Quote from MSDN:
After you finish updating the packages, you rebuild the project, copy the deployment folder to the target computer, and then rerun the Package Installation Wizard.
If you update only a few packages in the project, you may not want to redeploy the entire project. To deploy only a few packages, you can create a new Integration Services project, add the updated packages to the new project, and then build and deploy the project. Package configurations are automatically copied with the package when you add the package to a different project.