I'm trying my hand at writing a service using C# 2010 Express, and I'm hitting a roadblock at the very earliest step. The System.ServiceProcess Namespace doesn't appear to exist on my computer.
Put simply, the namespace appears to be completely missing. The only System namespace starting with S that exists is System.Security. Nothing else appears in the list.
I have both .Net 3.5 and 4.0 installed on this machine. It's a company computer, and thus built to someone else's exacting standards.
Do I need to download and install Windows SDK?
My guess is that you need to reference the respective assembly.
Yeah, so I looked it up:
System.ServiceProcess (in System.ServiceProcess.dll)
Related
I am using ActiveReports6 for my windows forms application
When I install it on my machine providing serial key it works perfectly fine.
But when I don't install it, it shows this red line in the bottom of the report
The document was created using an evaluation version of activereports..
My understanding may not be correct, but what I tried is I installed licensed version of ActiveReports6 to my computer and then copied all the dlls generated for ActiveReports6 from GAC and added them to my project thinking now they will work on any machine as they are generated by licensed version of the software.
And then uninstalled Activereports6, but when I tried it still gave me the same evaluation version message.
So is it mandatory that active reports has to be installed in all the machines where I deploy my client? Or I did something wrong
The license for development. You would install activereports, create your reports and build your application on the licensed machine, the VS compiler will automatically check the licensed components and include the license within your application. You do not need to install ActiveReports itself on your client, only make sure that you are deploying the ActiveReports assemblies with your application. if you are having any issues please contact us at http://activereports.grapecity.com and we would gladly resolve the issue for you.
Found the mistake I was doing.
Actually I had put licenses.licx file in the subdirectory of the project while it should be in the same directory of the project and so I was not generating its exe.licenses file and so did not work.
Once I changed the location of licx file it worked!
Thanks!
I have written an application that I deploy via Clickonce, but I want to deploy it via Installshield, so I am experimenting with it. I found and downloaded dotnetfx45_full_x86_x64.exe, the redistributable for .NET Framework 4.5, and made a Installshield prerequisite from it. I wrote a simple application that has a RDLC report that just says “Hello World”, and it needs .NET Framework 4.5, and used Installshield to deploy it. The Reportviewer needs Microsoft SQLClrTypes_x86.msi and SQLClrTypes_x64.msi, and ReportViewer.msi, so I got those and made Installshield prerequisites from them. For the ReportViewer.prq, I specified SQLClrTypes_x86.prq and SQLClrTypes_x64.prq, as dependencies, and for SQLClrTypes_x86.prq and SQLClrTypes_x64.prq I specified dotnetfx45_full_x86_x64.prq as a dependency.
When I installed my little application on my test computer (running Windows 7), it installed the 4.5 framework, said it needed to reboot, and asked if I wanted to reboot now, and I clicked Yes. I was thinking it would reboot and continue the installation, but when it rebooted, that was the end of the installation. I ran setup again, it asked if I wanted to install the 4.5 Framework (it asked me the first time, too), so I clicked No. After clicking No, it installed the rest of my program, and it ran perfectly.
How can I get the installation to continue after it reboots from installing the .NET Framework 4.5?
Thanks
Here's a blog I wrote about 9 years ago:
Using InstallShield 12 to Install .NET Framework 3.0
It hasn't changed much. You want to use the prereq editor to change the reboot behavior to Note it, fail to resume if the machine is rebooted, and reboot after the installation.
Also please note that InstallShield consumes it's PRQ files from the ISProductFolder (C:\Program Files (x86)\InstallShield.... ) I don't care for this from a CM perspective. I recommend isolating the file and file references to relative paths based on ISProjectFolder and keeping all of these files in your source control tool.
Behavior Tab
I have developed an application in Lightswitch 2012, and now need to deploy it to a desktop PC running XP SP3.
I have already looked at two previous posts Can't run Lightswitch 2012 Programm under Windows XP and
Lightswitch Desktop Application Wont Install in XP SP3
The two posts both refer to executing [editbin vslshost.exe /SUBSYSTEM:WINDOWS,5.01 /OSVERSION:5.1] to modify the vslshost.exe file, though only the first post says it worked.
In my case, I have tried the above to update the vslshost.exe file, but when I publish my LS2012 project it reverts back to the default vslshost.exe file. And if I manually swap the file with the copy I modified, when I run the deployed app I get the following error:
System.Deployment.Application.InvalidDeploymentException (HashValidation)
- File, vslshost.exe, has a different computed hash than specified in manifest.
- Source: System.Deployment
So, the questions are
am I doing something wrong?
is there a master copy of vslshost.exe I need to update instead?
(BTW, I also ran the VS2012 (KB270250 from VS2012 Update 1 CTP 4))
Thanks for your help
As this is an internal company app, I have just convinced our IT guy to upgrade the machine, because the certain grief of trying the different possible solutions was just too much.
BUT if you MUST deploy to XP
To find out more, here are two pretty exhaustive posts with input directly from the Lightswitch team:
Progress on LS2012 desktop apps installing AND running on XP yet?
Windows XP 32 bit deployment
Enjoy....(???)
Hello I have been fighting some complexities with understanding deployment of Primary Interop Assemblies (PIA) for MS Office. I have Visual Studio Com Add-IN built in VS 2008 on pure com technology (not VSTO see bottom of this for more on that), which references 2003 Primary Interop Assemblies but the add-in may be used on 2003, 2007 or now 2010 Office machines. Because I never know if the customer will be using 2003, 2007, or 2010, I cannot simply deploy one PIA version as a prerequisite (unless I make 3 installers which I do not want to do). Now, my understanding is that when you follow the steps here to add 2003 and 2007 PIA to the prerequisite lists that show up in a Visual Studio (2008) setup package, the prerequisites are smart enough to determine which office version is running on the client you are targeting. So if you were to select 2003 primary interop assemblies and 2007 primary iterop assemblies as both being prerequisites then when this installs on a machine that has 2003 it should be intelligent enough to only try to add the 2003 PIA if those are missing on this machine and if this is a 2007 Office machine then it will only install 2007 PIA (and not try to install 2003 PIA).
Question 1 is this a correct understanding (that the prerequisite packages are this intelligent to only install what it needs based on the version of Office?)
Question 2 is there a way to get the 2010 PIA to show in the list of prerequisites in VS 2008 like 2003 and 2007 do? I do not want to upgrade this project to VS 2010 b/c it is considered a legacy app now with many customers from all around the world using it.
Question 3 Even though the actual assembly references 2003 primary interops, I do not presently deploy those interops with the add-in to the install location. Instead, I am assuming that if I can get the correct PIA installed then I don't need this present in the installation path, since the PIA would be in the GAC. However, one possible approach may be to just include the 2003 assemblies that are referenced (in my case excel and word) in the install path and not worry about the PIA. I suspect this would work on 2003 machines but perhaps not on 2007 and 2010 machines b/c on the latter, even if the 2003 interops that are referenced are found at run time in the install path of the assembly, I think if there is not a Policy.11.0.Microsoft.Office.Interop.Excel/Word(etc) in the GAC, then 2007 and 2010 will likely not know what to do with the 11.0 (2003) interops (as I think the Policy.11.0.Microsoft.Office.Interop files redirect requests for the 2003 interops to 2007 or 2010). Any thoughts on this?
Question 4: There is a well known bug with Framework 2.0 apps Office Add-Ins and Office 2003 where the add-in won't load. This was addressed by KB907417 aka KB908002. Dopes anyone know if this KB necessary if you develop on the 3.0 or 3.5 framework (and make 3.0 or 3.5 a prerequisite) since this problem was specific to framework 2.0? Or does the KB still need to be deployed b/c it's office 2003 that is the problem and not the version of the framework?
As you can tell by my 3 questions what I am trying to ascertain is whether we can build one single installer via the VS setup utility. If the PIAs can be done with one installer but the KB above is the obstacle (as perhaps the answer will come back that even on the 3.0 or 3.5 framework 2003 customers will need the KB) then maybe the path to one installer is to just make the KB a prerequisite across the board and install it on 2007 or 2010 machines, though they technically do not need them. Any thoughts on that option would be appreciated as well. Finally, I am aware that writing a manged Com Add-IN for excel or word is now generally done with VSTO instead of pure managed framework code, but this is not an option presently to change the legacy app to this direction. Also it is reported that the 4.0 framework now can be used to deploy add-ins without making any PIA a prerequisite but again, this is not a viable option right now.
Does the code use any Office 2007+ methods or classes? If not, are you sure you cannot use the 2003 PIAs in all cases? The later apps should be backward-compatible (supporting the same API) so the only reason you'd need an updated PIA is if you needed to access some feature added by 2007 or later, I think.
You may want to take a look at Add-in Express, which promises a one-for-all-versions installer, and is pretty easy to use.
As you can tell by my 3 questions what I am trying to ascertain is whether we can build one single installer via the VS setup utility
You cannot. You must create custom installer packager (setup bootstrapper).
Many years ago I used dotNetInstaller with HTML GUI builder, today WiX toolset would be better solution, I think.
Check how PIA .msi installers are constructed with Orca or .msi and .exe installers flow checking windows installer logs.
Based on registry checks, file checks, installed product checks, windows versions, office versions you can create conditions whether component should be installed or not.
Oh and I advise making plugin installers without prerequisites and installing them conditionally with your custom installer bootstrapper.
For .net 3.5 SP1, Microsoft have the new client profile which installs only a subset of .net 3.5 SP1 on to Windows XP user's machines.
I'm aware of how to make my assemblies client-profile ready. And I've read the articles on how to implement an installer for ClickOnce or MSI.
But I've been using Inno Setup for my project so far and I'd like to continue to use it (as an Express user, I can't easily make MSIs), I need to know how to use the client-profile installer in a custom environment.
There is an article on a Deployment.xml schema, but no indication of how to write one, package it or anything else. Can someone explain this process? Finding the articles I linked to alone was a painful search experience.
Microsoft has now shipped the Client Profile Configuration Designer (Beta).
This designer lets you edit the XML files with some limitations, this isn't a 'Google beta' by any means.
Information and download
Can you clarify: Are you trying to write an installer for your app, which depends on the Client-Profile, or are you trying to write a custom installer for the client-profile?
I haven't used it personally, but if it's anything like the dotnetfx 1 and 2 msi's, you basically have to just invoke it's executable yourself from your own .exe file, or from an Msi BEFORE the InstallExecuteSequence starts up - you can't "embed" those in your own app, MS go out of their way to tell you not to do that due to suckage of MSI.
Client profile works only on clean XP. If your user as .Net 1 or 2 installed, client profile wont install...
You have an offline version (integrating Full .Net3.5 Install in case Client Wont install) 200 to 300Mo don't remember
Online version will get required files.
You can call a silent install from the first steps of your install.