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.
Related
I have an old webservice installer built on .netframework 4 which is running on Windows 2008 and when i try to install the installer on Windows Server 2016, i am getting the below error.
Error Message : "This setup requires Internet Information Server 5.1 or higher and Windows XP or higher. This setup cannot be installed on Windows 2000."
Is it possible to run this old webservice installer to the new 2016 without rebuild my solution?
LaunchCondition Table: Most likely there is an entry in the LaunchCondition table of that MSI - if it is an MSI - which prevents installation. I say most likely because it could also be a custom action - please check the launch condition table first and get back to us. Launch conditions must evaluate to true for the setup to allow itself to be installed. You can "hotfix" this by using a tool capable of writing to MSI files: How can I compare the content of two (or more) MSI files?
You are supposed to make a transform file *.mst (a database fragment) and apply it at installation time to change the original MSI installer. However, sometimes I make backups of the original installer and zap simple stuff like launch conditions if they are wrong in the first place. A transform becomes too cumbersome for ad-hoc stuff. But should be used if you intend to distribute through SCCM etc...
Compatibility: Even if you hotfix the MSI file and it installs you obviously won't see the webservice working if there are technical reasons why it won't work on that machine. Launch conditions are a sign that something must be present on the machine for the application to work. However, sometimes people are a bit trigger happy with their launch conditions and make packages that are a bit too restrictive.
Note: first check if IIS is installed on the box.
I am trying to run a Test package created using SSDT BIT for Visual Studio 2012. This package is ran from a Windows Forms application created in Visual Studio 2012 but i get the error message "To run a SSIS package outside of SQL Server Data Tools you must install Check for non Matching Data of Integration Services or higher.
"
Please Note
I have SSDT and Intergration Services installed in SQL Server 2012.
Initially the package executed successfully, it only consisted of an OLEDB Source and an OLEDB Destination. I started getting the error after adding a lookup which checks for non matching data.
were are you running this Forms application, on your machine or from a different machine than yours?
how is the application calling the package? you probably have a reference issue that you need to figure out. i assume if you were to execute the package from the command line, it will produce the same error.
add an explicit reference in your package to the "lookup transformation" dll, and see if that helps.
I've inherited an application from a former co-worker. It's a C# ASP.Net Web Application. When I try to compile it in Visual Studio 2008, it complains that it can't find the DTS namespace. So I added the DTS.dll file to References from C:\Program Files\Microsoft SQL Server\100\DTS\Binn. When I do that, all compile errors go away, but I get two warnings that look pretty nasty to me:
"Cannot find wrapper assembly for the type library DTSLib. Verify that (1) the COM component is registered correctly and (2) your target platform is the same as the bitness of the COM component. For example, if the COM component is 32-bit, your target platform cannot be 64-bit."
and
"The referenced component DTSLib could not be found"
Also, DTSLib in the References in Solution Explorer has a yellow exclamation point next to it.
First, am I correct to be concerned about this? Second, if so, how do I solve it? It's not a question of the bitness, since I'm working on a 64-bit machine and took the dll from Program Files, not Program Files (x86).
#Melanie: DTS has a some support issues in 2008, due to the creation of SQL Server Integration Services. https://msdn.microsoft.com/en-us/library/bb500440%28v=sql.105%29.aspx?f=255&MSPPError=-2147217396
I hope the support issues have been ironed out if the client is also on SQL Server 2008 R2.
What the most likely problem is is you do not have the packages fully installed. This is rather easy and handled by following the instructions at https://msdn.microsoft.com/en-us/library/ms143755(v=sql.105).aspx - essentially a backward compatibility "hack".
The problem may be the failure to register some COM components, which may or may not exist on drive. Most likely do, as you can follow the instructions above, but they may also be copied and registered at the time.
The reason I asked which version is you would have had to do a repair if they were still on a version like SQL Server 2000.
I would recommend the company invest some time in updating to SSIS, as they are not going to be able to migrate to SQL Server 2012 or 2014 if they still wish to do DTS. It was deprecated in SQL Server 2005, support reduced further in 2008 (with some limitations) and gone as of SQL Server 2012. Actually, there is a hack they might be able to do, but I have not tested it (and do not recommend it, if so).
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 am upgrading lots of C# projects from vs.net 2008 to vs.net 2010 rc. I notice that the upgrade creates a BootstrapperPackage section inside the *.csproj file (include Microsoft.NET.Framework.3.5 and 3.5sp1). I wonder what the BootstrapperPackage does and do I need them?
Bootstrapper packages are the basic components you might need to get a .NET program installed. You'll find them listed in the BootsTrapper\Packages subdirectory of the Windows SDK folder (c:\program files\microsoft sdks\windows\v6.0 for VS2008). The ones on my machine are:
DotNetFx(Xxx) - installs .NET on the target machine
Office2007PIARedist - the Office PIA, required when you automate Office programs
ReportViewer - required when you use report viewer
Sql Server Compact Edition - required when you use SQL Server Compact
SqlExpress - required when you use SQL Express
VBPowerPacks - required when you use any VB Power Pack component (PrintForm, Shape etc)
vcredist(Xxx) - required when you used any C/C++ code that uses /MD
VSTOR30 - required when you used VSTO
WindowsInstaller3_1 - installs MSI 3.1 (don't ask)
Making sure that .NET is installed isn't really necessary anymore today. The rest of them might however be required, even if this is a CO install. I think a Setup project can autodetect them reliably.
<BootstrapperPackage> is the item name for parameters to the BootstrapperItems parameter of the <GenerateBootstrapper> task, in the default project configuration (ie: Microsoft.CSharp.targets). Check here on MSDN for the documentation.
(So the name "BootstrapperPackage" is arbitrary - which is why documentation for it is difficult to find.)
The GenerateBootstrapper task creates a "setup.exe" that checks for and installs the specified prerequisites before launching another application. Typically that other application will actually be a ClickOnce manifest describing how to install your program.
(The ClickOnce manifest gets opened by Windows Installer, which is why you'll typically have that as one of the prerequisites.)
OK Found a link. It has something todo with ClickOnce and nothing I need to worry about, I think.