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.
Related
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.
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.
(Background: Just started using VC# and .NET)
Hi, I have a simple project which I started developing on Win7 (Pro), using VC# Express edition. It works well when I send it to the client who wanted to use it on Win7 Pro. I used to use "Build -> Publish" to generate the setup.exe and the relevant files. (Both development and client machines are very similar, Win7 Pro, 64-bit etc)
However, now the requirement changed and the client wants to use it on a different machine which is on WinXP Pro (32-bit) and it doesn't have an internet connection (it cannot be ever put on internet).
I used "Any CPU" option, made sure that the .Net version matches (Both have ver 4.0 Client profile". Since this PC will not have internet connection, I unchecked "Create setup program to install prerequisite components".
The program installs on the XP machine, but when it tries to launch it displays an error dialog "encounted a problem, need to close, send an error report to MS".I am not before the XP machine,so I don't know the "details" part of it.
I installed VC# 2010 express on the client machine and tried to open the solution file, but I get an error saying that the solution file cannot be opened because it was created with a newer version of VC#.
Ideally I would need to generate an installation file, which will uninstall the previous version and use a newer version (we need to go back and forth on any changes). But that is not a requirement as of now.
Any idea how should I go about getting this program installed on a WinXP machine? I don't have access to an XP license to test it in a virtual machine.
Thanks.
I have developed a solution in Visual Studio 2008 C# WPF!
I'm using a service-base SQL database (I've created and managed using Microsoft Visual Studio Sever Explorer), now I'm going to publish it but the problem is that when I install .NET Framework 4.0 and SQLEXPRESS 2005 on other systems, my application doesn't launch! :-(
What componenets should I install on the systems to make it runnable?
If you develop with Visual Studio 2008 you will probably need to install .NET Framework 3.5 with Service Pack 1.
If that is not enough you need to post the error you get. Probably in the eventviewer you will see more info.
You can try to create a setup using Clickonce. To do this you need to go to the property pages of the WPF project an go to the tab Publish.
There you can choose to publish it to the network or to a local directory which can be put on a CD or USB device. The most important thing for you to check is the button "Prerequisites".
I hope this helps!
EDIT to help with the comments:
It is perfectly possible to put the prerequisites in the same folder as the install or even better in a fixed network location as you can see in this screenshot below
I've written an app that connects to websites APIs and does some things there. It is a app written in C#, .NET 3.5 on a XP OS.
Now I have a problem. Some people reported that this application hangs on Vista, and not on the more new version of Windows (what was the name?)
So I do not have Vista and do not have money to buy this system only to test this one, freeware application. Is there any other way to test my app if it is valid for Vista or is there other way to make sure it will be working? I'm in a blind spot here and do not know what to do next.
Update: I use Visual C# Express 2008
Use a trial version of Vista?
On one of my small projects, I've worked out some miscellaneous bugs by connecting to users over Remote Assistance before. At least Visual Studio Shell Edition (free) will let you attach to an existing process, and probably C# Express Edition (free) as well.
(This was an obvious choice for me, since my program is a Visual Studio extension, therefore all of my users have Visual Studio installed.)