Recently I tried to deploy SSIS packages on our production environment and after struggling with some errors I checked contents of packages by importing them from server(not from deployment file) into SSDT. What I found was really interesting - C# code from Script Task(we got only one script task) was gone, there was only template code even with comments that you see when you add Script Task to your package, it looked like it wasn't ever edited by anyone.
I asked my colleague if he could deploy same project on same server instead of me, and it worked, code was on it's place and everything went smooth from there.
What may have caused this behavior? We both are server admins, we both have sysadmin permissions on SQL Server and we don't know about any permissions that he has and I don't.
EDIT: We were both deploying same .ispac project deployment file, none of us edited it after it was "production ready". We also deploy it in the same way - double click on .ispac file, and using Integration Services Deployment Wizard.
Packages are prepared on different server.
I have experienced a very similar problem. A previous post existed which may have been subsequently removed, but I can attest that the process script task in the SSIS packages are being replaced with an empty or default Task. I suspect an incompatibility in versions or a dll found in the SQL Server\120\DTS\Binn directories.
We currently developed using Visual Studio 2013 Professional with SSDT integrated into it (did not use the shell or standalone version). Development took place on a Windows 7 Enterprise 64-bit machine with SP1. All testing was fine locally using SSDT. When deployed to the server, testing worked as intended. The server is where I believe the problem is originating. We deployed to a SQL Server Enterprise Edition running on Windows Server 2012 R2. Microsoft SQL Server 2014 (SP1-GDR) (KB3194720) - 12.0.4232.0 (X64). The ispac was generated from an export in SSMS in the SQL Server Integration Services Catalog. The ispac was then deployed to another site.
Turns out the site had deployed this to a SQL Server Developer 64 Bit instance. Theoretically, this should work, but when importing the deployed project back into a Visual Studio SSDT standalone instance (not embedded in Visual Studio Professional) at this site, all the Process Script Tasks were replaced with the default instance of a Process Task.
When reproducing the scenario in-house, on a SQL Server 2014 Developer 64 Bit as the deployment site, and then importing it back into a new Visual Studio SSDT project, the Process Scripts are indeed replaced. When creating a new Visual Studio SSDT project and importing them from the Enterprise Edition, the Process Scripts are all there.
For us, it seems to be a strong correlation between the SQL Server versions, or the fact of them being different.
Related
I know this has been asked many times before but I haven't found a solution to my specific problem.
My setup is a newly installed Windows 10 Enterprise fully updated with SQL Server 2017 incl Integration Service and Analysis Service. I've installed latest SSDT as well. I've also installed client tools SDK from the SQL Server 2017 installation.
Visual Studio 2017 is installed as well.
My ASP.NET application 'should be' running SSIS packages, but it fails when loading the package using LoadPackage(packageName, null).
The error is "an integration services class cannot be found etc etc.....".
Just to repeat - Integration Service 2017 and Client Tools SDK are installed.
My application has been working on previous SQL Server versions - the most recent version is with SQL Server 2014, but I've upgraded my application from SQL Server 2008 to 2008R2 to 2012 to 2014 and I've never met problems before.
What is different from other posts I can find is that I do not deploy the SSIS package to a separate web server (well, I do and that doesn't work either but a first step is to solve it on my dev machine).
I have created an empty SSIS package in VS2017 to ensure it is not the content of the package that causes the error.
The SSIS package is developed on the same machine, and I can run the package with both 32 and 64 bit versions of DTExec.exe successfully.
I have updated any references in my ASP.NET application to ManagedDTS.dll version 14.0.
I've updated my ASP.NET application to .NET 4.7 as part of this update to SQL Server 2017.
As I can easily search and find many posts about similar problems with lots of solution suggestions, I hope someone will reply to this with solution suggestions rather than links to 'copies' of my question, as chances are I've already read those and tried all suggested solutions.
Thanks in advance...
UPDATE:
First of all, creating a new project and loading a package works - so I figured that I might be facing a problem with the code after updating from .NET 3.5 to 4.7.
I started commenting code and found that if I don't do impersonation before calling LoadPackage, it actually works.
Based on some other issues I've had recently with the July updates from Microsoft, I have removed one of the updates and I now get a different error - with the impersonation code enabled.
The current error is one I've seen many other people have so I'll dig into that - it is: "The package failed to load due to error 0x80131534 \"(null)\". This occurs when CPackage::LoadFromXML fails.\r\n".
I don't really understand if this should be caused by a mismatch between versions, but I'll update as I find out more.
If anyone has good suggestions, I'd be happy to hear them :)
As a quick WORKAROUND, you can set sql job calling the ssis package and run the job using the sp_start_job stored procedure from the asp.net app.
If the running job needs to be monitored, status can be checked using:
select * FROM msdb.dbo.sysjobactivity
I have a WPF C# app (.Net Framework 4.5) which I regularly updated and published to an FTP server using ClickOnce (every few months). Now, when I want to publish it to the FTP server, it fails with the following error message: The components for communicating with FTP servers are not installed.
Searching the web and StackOverflow, I read that in some cases Xamarin prevents publishing it, so I uninstalled Xamarin (as advised), but the problem persists. I also tried to publish locally and then manually copy the files to the FTP server, but then Windows Defender blocks the installation for the user. I also updated Visual Studio Enterprise to the latest version (Update 2).
It seems this issue has been there for quite a long time (one, two, three). Does anyone have an idea how to solve the issue, or what else I could try?
kurtdv on MSDN suggested to install the 32-bit version of Visual C++ Redistributable Packages for Visual Studio 2013 from https://www.microsoft.com/en-us/download/details.aspx?id=40784, which solved my problem.
I'm working on a C# project for windows mobile 6.5 and as of this morning I'm getting "Reference package not found. Device Connectivity Component" whenever I try to deploy.
It builds without errors and was working up until today. I did a bit of looking around and only found dead ends online. As far as I can see there are no clues about that component or package this is a reference to. I think it may be related to Windows CE SQL Compact but that's based on nothing. I've rolled back to an earlier version of my code and cleaned a few times. I'm stumped.
I would greatly appreciate any help even diagnosing this a bit further. I'm using Visual Studio 2008 3.5 SP1
Update: When I disable "Deploy latest version of the .NET Compact Framework (including Service Packs)" it does deploy but then throws errors related to the SQL database which worked previously. assumedly because it doesn't have access to the correct SQL packages.
Update: I also get the same error with the emulator, it builds, the emulator starts but can't deploy, giving the same error.
Update: I think this might have something to do with it. Note the double slashes in the path. I keep removing them. It keeps coming back.
Update/Correction: I can now deploy to the emulator, I had a problem before but it seems to be ok now. I still can't beploy to the device, same error.
For anyone who was pulling their hair out like me. I couldn't figure out what was wrong although I still suspect it was something to do with the .NET compact package. Eventually I created a new project, set up the references and copied and pasted the code over. It's not a nice solution but it worked after days of being stuck.
HA! I found it! This may not be your solution, but this was how I did it.
See this REF: http://msdn.microsoft.com/en-us/library/aa983326(v=vs.90).aspx
Since Microsoft is bad about deleting their old info, I'm going to post it here, too. But basically, if you select a Private Deployment, then Microsoft Updates will not influence your project or update your 3.5 databases to ...whatever the newest stuff from Microsoft is.
How to: Deploy a SQL Server Compact 3.5 Database with an Application
You have two deployment options for applications that contain SQL Server Compact 3.5 databases. The method of deployment you choose depends on the servicing requirements of your application and whether your users will need administrative credentials on the computer on which the application will be installed.
Following are the deployment options for SQL Server Compact 3.5 databases:
Traditional Microsoft Windows Installer (Microsoft setup technology)
Users need administrative credentials to install the application.
SQL Server Compact 3.5 will be serviced by Microsoft Update.
Can use ClickOnce deployment.
-or-
Private file–based deployment (deploying the SQL Server Compact 3.5 DLLs as part of the project)
Users do not need administrative credentials to install the application.
SQL Server Compact 3.5 will not be serviced by Microsoft Update.
Can also use ClickOnce deployment.
Traditional Windows Installer
Traditional Windows Installer technology is used in both standard Setup and Deployment projects and in ClickOnce deployment. When you deploy a SQL Server Compact 3.5 database, ClickOnce deployment provides an option that automatically installs SQL Server Compact 3.5 if it is not detected on the target computer. For this reason, ClickOnce is the preferred method of deployment for applications that include SQL Server Compact 3.5 databases (as opposed to creating a custom action in a Setup and Deployment project).
ClickOnce deployment has been updated so that it automatically includes the SQL Server Compact 3.5 runtime as a prerequisite for applications that include SQL Server Compact 3.5 databases. It also recognizes .sdf files as data files and sets these to the correct publish status.
Creating a ClickOnce deployment for an application that contains a SQL Server Compact 3.5 database consists of configuring the proper publish information in the Project Designer.
To use Windows Installer technology for ClickOnce deployment of an application that contains a SQL Server Compact 3.5 database
To open the Project Designer, in Solution Explorer/Database Explorer, double-click My Project if you are working on a Visual Basic project (or Properties if you are working on a C# project).
Click the Publish tab.
Click Application Files and set the .sdf file to Data File (Auto). (This setting notifies the installer to treat this as a local data file and to put it in the Data Directory.)
Click Prerequisites and select SQL Server Compact 3.5. (This setting notifies the installer to check whether the SQL Server Compact 3.5 runtime exists and to install it from the Internet if it is not found.)
Creating the Installer After the publish information is configured, create the installer.
To create the installer
In the Publishing Location box, type the Web site, FTP server, or file path to publish the installer to.
Click Publish Now to create the installer.
The application is ready to be installed. Go to the location you published to, and install the application to verify.
Private File-Based Deployment
Private file–based deployment refers to the process of including the required SQL Server Compact 3.5 DLLs as files in the project (as opposed to a reference to DLLs already on the target computer). If you include the necessary DLLs with the application, the requirement to install SQL Server Compact 3.5 is removed. Therefore, the administrative credentials are no longer needed.
You can use ClickOnce deployment technology for private file–based deployment. If you do, you must remember to clear the SQL Server Compact 3.5 prerequisite so that the Setup program does not install it.
To deploy a SQL Server Compact 3.5 database by using private file–based deployment
To open the Project Designer, in Solution Explorer/Database Explorer, double-click My Project if you are working on a Visual Basic project (or Properties if you are working on a C# project).
Click the Publish tab.
Click Prerequisites and then clear the check box for SQL Server Compact 3.5.
Close the Project Designer.
Go to the directory that contains the SQL Server Compact 3.5 DLLs. These are located in C:\Program Files\Microsoft SQL Server Compact Edition\v3.5.
Select the seven SQL Server Compact 3.5 DLLs and copy them:
sqlceca35.dll
sqlcecompact35.dll
sqlceer35EN.dll
sqlceme35.dll
sqlceoledb35.dll
sqlceqp35.dll
sqlcese35.dll
Paste the DLLs into the project in Solution Explorer/Database Explorer.
Select all seven DLLs in Solution Explorer/Database Explorer and open the Properties window.
Set the Copy to Output Directory property to Copy if newer. (This will replace any earlier DLLs in an existing application with the newer ones if the application is updated.)
Click the Show All Files button in Solution Explorer/Database Explorer.
Expand the References node.
Select System.Data.SqlServerCe.
Set the Copy Local property to True. (Because your development computer has the SqlServerCe DLLs in the global assembly cache, you must configure the application to use the DLLs in the output directory.)
Right-click the project in Solution Explorer/Database Explorer and select Publish to open the Publish Wizard.
Complete the wizard to publish the application.
The application is ready to be installed. Go to the location you published to, and install the application to verify.
I had the same problem. I got it to work by closing visual studio, renaming the directory:
C:\Documents and Settings\\Local Settings\Application
Data\Microsoft\CoreCon
Then reopening visual studio and the deploy worked.
i finally finished a proyect i was requested in my university with Lightswitch. Im ready to deploy (publish) next week, and i was JUST told that the people that will recieve the software, are using XP machines. I've read a lot of questions and lots of fixes, to get Lightswitch working on Windows XP, like:
Changing the DumpBin with "editbin vslshost.exe /SUBSYSTEM:WINDOWS,5.01 /OSVERSION:5.1"
deploy it as a desktop application with the services deployed to IIS (i dont think this will work because those are really old pc's)
install all the prerequisites manually and launch the ClickOnce application directly from deployment manifest file (.application)
create a sample ClickOnce application using Visual Studio 2010 OR Visual Studio 2008 with the same name as mentioned in Visual Studio 2012 and publish it. From the published location take the setup.exe bootstrapper and replace the existing setup.exe bootstrapper created using Visual Studio 2012
With all of this workarounds available, i NEED to ask, will this ultimately work? Can someone REALLY tell me that using one-or-all of this workarounds i WILL be able to deploy the application!?
Someone?
The 2-Tier Deployment issue on XP was also addressed in VS 2012 Update 2 IF you upgrade to a "V3" LightSwitch project by right-clicking on the root project in Solution Explorer and selecting "Upgrade Project". This updates the project to the "V3" project system, runtime and will use a much newer publish wizard. The version of VSLSHOST.exe that ships with VS 2012 Update 2 is compatible with XP.
Dave Kidder - LightSwitch team
http://social.msdn.microsoft.com/profile/dave%20kidder/
I have a successfully deployed application using the 3-tiers running as an out-of-browser (desktop app) on XP. Initially I was going to do the 2-tier deployment, but I was unable to get a workaround to work.
So I have one server, which runs IIS as well as my SQL server (OS is Windows Server 2003, but doesn't have to be.)
The client machines range from Windows XP to Windows 7, and I haven't had any special problems with windows XP.
So I can definitely say XP will work as a client. I was unable to get it to run the middle tier (hence IIS on the server) but I didn't try every last idea I found, so I won't say it's impossible.
The two links I found most helpful in the process were
http://blogs.msdn.com/b/bethmassi/archive/2011/03/23/deployment-guide-how-to-configure-a-web-server-to-host-lightswitch-applications.aspx
and
http://blogs.msdn.com/b/bethmassi/archive/2012/03/29/lightswitch-iis-deployment-enhancements-in-visual-studio-11.aspx
Hope that helps.
I have a winform solution that I deploy through clickOnce. There is the Main Project and then a Project called psWinForms. That project has a Reference to Microsoft.ExceptionMessageBox that I use in my custom error reporting.
I have psWinForms as a reference in my Main Project with Copy Local = True.
I have Microsoft.ExceptionMessageBox as a reference in psWinForms with Copy Local = False & Specific Version = False
In Application Files I have Publish Status =Prerequisite(Auto)
I have tried various combinations to no avail.
I looked here on the Test System on the DLL is there.
C:\Program Files\Microsoft SQL Server\90\SDK\Assemblies
I am using the ExceptionMessageBox from SQL version 9.0.242.0 if that makes a difference and the users only have SQL 2005 Express(9.0.1399.0) installed.
So I am very confused as to why my app hangs when I try to throw an error using this....
You can't copy and deploy the assembly yourself, it has to be installed as part of the SQL client components. There are different client components for SQL 2008 and SQL 2005, your application has to reference the proper one. So you'll have to ship two different applications, one compiled for SQL 2005 and one for SQL 2008 and your users will have to install the proper one. From Deploying an Exception Message Box Application:
The exception message box is installed
by Microsoft SQL Server and is
supported for use in your custom
Windows applications to improve
exception handling. Because the
exception message box is installed by
all editions of SQL Server except SQL
Server Compact 3.5 SP1, you can use it
with no additional configuration on
any computer on which SQL Server
client components, including the SDK,
have been installed.
While technically is probably possible to deploy the assembly and add it to the GAC yourself is a bad practice as your dll will not be part of the normal chain of service packs and cummulative upgrade patches.
Also you better clear up with an MS representative whether deploying this dll standalone is OK with the SQL client usage license or not. Every component that can be redistributed under the license has an install msi available for developers to distribute. If this dll does not is a strong indicator that is not allowed to be redistributed by 3rd parties (you).
Update
There is actually a distributable msi (SQLServer2005_EMB.msi, SQLServer2005_EMB_x64.msi) for the ExceptionMessageBox component:
In SQL Server 2005 SP1 and later
releases, the exception message box is
also provided as a redistributable
installation program that you can
distribute and deploy with your
application... The redistributable
installation program for exception
message box is available online as
part of the Feature Pack for SQL
Server 2005 SP1.
do you have the assembly referenced in your MAIN application? I didn't see that scenario listed...I have found that for copy local to work, you need to have all sub-projects references in the main application reference list otherwise you get unpredictable results.
Also if you need your specific file to be used, make sure use specific version is true.
the same goes for App.config sections...if you have project level appconfigs you have to merge that with the application level app.config.