I'm trying to create a deployment package for a windows service targeting x64.
I've made the setup project itself target x64 but I need to add custom actions to actually register/unregister the service.
However, when I add custom actions and try to run the installer, I get a BadFormat exception which indicates that the executable for my service is corrupted.
I suspect I'm running into the issue mentioned here but am unable to prove it.
This windows service is being developed as part of a far larger application using TFS for automated builds and deployment, continuous integration, etc - So manually tweaking bits of a binary file using tools which require the use of a GUI is a definite no-no.
So... What I need to know is; Is it possible to automatically build a deployment package for a 64-bit windows service in VS2010? If so how?
This will happen when either your service or one of the assemblies it uses was built with the Target Platform setting changed to x86. In which case you have to use the right version of Installutil.exe to register the service. There are two, in c:\windows\microsoft.net\framework and \framework64, respectively the 32-bit and the 64-bit version. Odds are good that you need the former. If you created a Setup project then you'd change the TargetPlatform property to x86.
Also check if you really need to have the target platform set, you only do if you have a dependency on unmanaged code like a COM server. The C# setting is in Project + Properties, Compile tab. The default for VS2010 is x86, just flip it to AnyCPU if you have no such dependency.
Related
I'm trying to use Visual Studio to develop and debug a web application that uses the SharePoint 2007 API. I have been doing this fine on a 32-bit server up until now. Today I've moved over to a 64-bit development server and when I try to run the project out of VS, I get:
Could not load file or assembly 'Microsoft.SharePoint.Search, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. An attempt was made to load a program with an incorrect format.
I have referenced Microsoft.SharePoint.dll and Microsoft.SharePoint.intl.dll from the GAC on this machine. That automatically copies in Microsoft.SharePoint.Search.dll from somewhere when I run it (even though copy local is false on the references). My project Platform Target is "Any CPU". I get the same error with x86. If I change to x64, I instead get Could not load file or assembly 'MyProjects.dll'...incorrect format.. I've also tried deleting Microsoft.SharePoint.Search.dll from the bin after it starts up but then I get a SharePoint error saying that the site at my URL can't be found, which I believe is also a bitness issue. I'm not quite sure what the issue is but want to be able to run this application out of Visual Studio. How can I get it working?
You need the x64 (or anyCPU) version of the Sharepoint dlls to make it work
Both Microsoft.SharePoint.dll and Microsoft.SharePoint.intl.dll in the server's GAC are built for Any CPU. When I build my web app in Visual Studio, it automatically copies Microsoft.SharePoint.Search.dll into my bin, presumably because it's referenced by Microsoft.SharePoint.dll. SharePoint.Search.dll is not in the GAC. It is copied from the 64-bit 12\ISAPI directory and is built with an "Amd64" target architecture (despite my server having an Intel Xeon CPU). So I believe the problem is VS runs the web app in a 32-bit process which causes the error when it tries to load the 64-bit SharePoint.Search.dll.
My first idea was to explicitly reference the 32-bit SharePoint.Search.dll in my project. That makes the error go away but it is replaced with an error saying the website at [my SharePoint site URL] cannot be found. I believe this is because now I'm trying to access the SharePoint site, which runs in a 64-bit app pool, from a 32-bit process. So what I really need is for Visual Studio to run my web app using a 64-bit hosting process. This looks like an option available for VS 2012, but not 2010. The alternatives I've found for VS 2010 are:
On the project properties Web tab, configure it to run using the Local IIS instance. This will add a virtual directory to the default site, which is running in 64-bit mode by default. This isn't a good solution for me because I want to allow multiple developers to work on the same project on the same server simultaneously. Using the same site would cause conflicts. If there were a way to configure the site name conditionally on the user, this would be ok. I opted to try #2 first.
Replace the VS Development Server with an x64 build of the CassiniDev project. This project has the capability of plugging in to VS in place of the default WebDev.WebServer.EXE. So you just need to download the source code, and build with an x64 target platform. Then you can replace the VS default development server exe, as is documented w/ the CassiniDev project, and it will run an x64 development web server which solves my problem!
I have a windows service that installs and runs fine. I want to create an installer/msi bundle that contains the windows service + other .dll files. And when I run the msi, I want it to run the service and the dlls'.
Currently I am at a point where I have a SetUp project which can install and uninstall the windows service that I created. And the dlls that are being used for a specific task also work fine individually. I want a package that would initiate these 2 tasks.
Do I need to use any third-party package creation wizards? Please guide me to achieve this.
Thanks in advance.
I don't understand what you mean by "specific task" regarding your DLLs, since DLLs are not executed directly... does your service depend on those DLLs?
I don't want to do commercial but I used http://www.advancedinstaller.com/ with the enterprise license (1k$) for very very easy complicated MSI functionality.
What are you doing with those DLLs? Just install them?
//
Well you can easily deploy your service and related DLLs, and registry settings, .... with that tool i mentioned, but its not for free. But this should be possible without it, I just don't know any tool that gives you an easy interface to creating such MSIs. I don't have any experience with the Visual Studio integraded MSI generation / install projects.
You could "try" the trial ;) The basic/free version does not support this.
I have a package I am putting together that contains the following components:
Core windows service
Core web service ( requires windows service )
Secondary web service
Front end
This is designed for a distributed configuration, where the Core Windows and Core web services have to be installed on every machine, the Secondary web service only needs to be installed on one machine and the front end only needs to be installed on one machine.
All four can be co-located on one machine but aside from the core services having to be installed on the same machine they don't have to be.
All four projects have x86 and x64 variants.
Currently I have an installer for each component built as VS2010 deployment projects. This works fine, but it means a lot of files have to be copied and installed before we can get going and it is far too easy to miss one out. I would like to have an integrated installer that pulls them all together and then allows the user to suggest which components to install on any given machine.
Is there a way to do this with a Deployment Project in Visual Studio 2010? I don't believe I can chain MSI packages, but could I create a single one that deployed the windows service and web services to their various locations in such a way that the windows service was guaranteed to be installed before the web service and that all components can be optional with no installation directories created for components that aren't installed? If so, is there anything I can do to ensure that users only see relevant parts of the interface- showing panels conditionally based on previous checkbox responses or similar?
If not is the best alternative ( as suggested in this question ) to put together a simple Forms application to package the files up and chain them manually?
Take a look at Wix (Windows Installer XML). http://wix.sourceforge.net/ Its an add on to visual studio. You can create much more powerful and flexable msi installers with it than with the default VS projects.
I have a Windows .net solution that is deployed with a Visual Studio Deployment project.
My exe is a win32 app that runs fine on either a x86 or x64 windows.
However I included a merge module (*.msm) from a third party vendor which is available in a x86 and x64 version.
Now I could copy my whole deploy project and just change the msm, but I'm a lazy guy and the best thing would be to include both msm's in my installer and only install the module which fits the processor of the client machine.
Is there a way to do this with Visual Deployment projects?
Merge Modules seem to lack a Condition property like included exe / dll files have.
I have the Target Framework set to 2.0 on my windows application, yet when I try to install my app on the server, after publishing it through VS 2008, it is trying to install .Net 3.5 on the server.
I do not want to install 3.5 on my server.
When I copy the files from my local /bin/debug/ to the server and double click on the exe, nothing happens. On my local machine, my app runs.
How can I make this app run on the server without it needing the .Net 3.5 framework?
Do any of your dependencies require .NET 3.5? Do you have anything in any config files which might require .NET 3.5?
I suggest you take a copy of what you've got for safekeeping, and then cut it down to the very smallest app which demonstrates the problem. In fact, you might want to start from scratch with a "no-op" app and see whether that has the same behaviour.
Check unused references, perhaps? Are you actually getting an error about the 3.5 framework?
Try building the application in release mode and deploy it to the server. You will need to grab the application from the /bin/release folder instead of the /bin/debug folder.
Also, check the target framework under the application section of the project properties.
If you're using Visual Studio to build your setup project, open the setup project's properties and look through the settings. One setting says which .Net version will be demanded by the installer package. You have to set that; it doesn't inherit from known properties of your other projects.