I am building a simple installer for a web application using Wix. I wish to use an existing app pool. The following code works as I want when installing the application.
<iis:WebAppPool Id='MyAppPool' Name='CRMAppPool' />
This will set up the virtual directory using the existing CRMAppPool.
The problem is when, I uninstall the application, it deletes the app pool.
How can I prevent this?
Put the WebAppPool element in it's own component and mark the component as permanent. The permananent attribute will ensure that the component is not removed upon uninstallation.
First I'd like to ask why you want to do this. I've always been really paranoid about sharing app pools once I first learned years ago that a .NET 1.1 webapp could JIT and then a .NET 2.0 webapp would fail.
Assumming you've considered all of this and really do want to share the app pool, I wouldn't do it with a permanent component and described above. I would instead do it with a shared component. Since App Pool's can't really be keyfiles I would create a fake registry key that services as the keyfile and put the app pool in as a companion resource.
I would then duplicate this component across all of my installs so that MSI can reference count the component and when the last install comes off the machine it will remove the app pool.
Related
We have already delivered the 1.0 version of our Worklight application. By mistake we have disabled the Direct update feature by updating the attribute "connectOnStartup = false"
We dont want to redeploy the application to markets (AppStore/GooglePlay) again, but wanted to make our users to utilize the direct update feature. We do have the access to WL server.
Our issue is little different from the one which is already discussed here "IBM Worklight - How to disable Direct Update?"
How can we provide the direct update feature to our end users without redeploying the application to AppStore/Googleplay. And just by changing the Webresources of the application.
We are using the adapters in our application but no where we are explicitly calling the "WL.Client.connect".
The Direct Update feature is always enabled by default.
You need to edit your question and explain what it is you've done in your Worklight project.
The feature will not work if:
You have set connectOnStartup:false
You are not using WL.Client.connect
You are not invoking adapters
You disabled it via the checkbox in Worklight Console
Otherwise, the feature will work, and a check for Direct Update will be performed:
On application startup
On return to foreground
The application will need Re-deployment on the App stores.
So the solution to your problem is
Rebuild the Application with connectOnStartup:true.
Redeploy the Application on App Stores
Once the users download the updated application, future updates will go to the users directly.
While rebuilding, make sure that you change the Version of your application within ApplicationDescriptor.
I have created an application that exposes a OSX service for certain file by adding an NSService entry into my applications info.plist (as in http://www.macosxautomation.com/services/learn/), but I find that upon installing my application on a new machine the service doesn't show up quickly in the finder right click context menu.
I know that this is because pasteboard services hasn't re-indexed the /Applications folder and "discovered" the newly installed service.
I also know that I can force a re-index and discovery by manually running /System/Library/CoreServices/pbs.
The question here is what is the best way to ensure that my service shows up as quickly as possible for users who are installing my application for the first time.
I could execute a system call to "/System/Library/CoreServices/pbs" when my application starts up --If the user immediately starts my application--, but that only partly solves the problem (in addition I wonder if there is a better Cocoa API based way of doing this).
If my application is generally only accessed via the context menu, a user will never think to go out and start the application in the first place. They will only think it is broken when the context menu isn't there.
I am not distributing my application with an installer. I am simply providing a bundle that can be dragged and dropped into /Applications (as I believe Apple usually suggests).
Is there a way to expedite the process of service discovery when doing an installation in this fashion, so that there isn't any period of time where the user is without the newly installed service?
As a side note, it appears that the problem may not exist in 10.8 (or at least be as pronounced). Apple may have made this indexing happen more quickly in their most recent release.
I've actually ended up using
system("killall pbs;/System/Library/CoreServices/pbs -flush");
in one of my apps, just as you describe, though it's a long time ago, when 10.5 was in question as well.
You might want to try this function, however:
void NSUpdateDynamicServices(void)
which according to the documentation acts just like flushing pbs, but is a cleaner solution.
Also, if (according to your description), the app is nothing but a service, consider making it a really just a service - see (Installing the Service)
To build a standalone service, use the extension .service and store it in Library/Services.
I am now facing a very strange issue. One of our product installers registers numerous COM DLLs during the installation of the product. Subsequently, this creates COM+ applications under Administrative tools --> Component Services --> COM+ applications.
One of the COM+ applications is created during the install to run under NETWORK SERVICE account. However, at times , it has been observed that the identity of this COM+ application is set to interactive. I am using a msi based installer. The windows installer log files clearly state that the COM+ application was set to run under NETWORK SERVICE account.
We use our own custom code to create this COM+ application. This issue is not reproducible at will. However, it does happen on some environments.
Either of the two things is happening:
There is a bug in the installer code which is causing this
There is something outside of install which is causing this.
I need to determine the root cause of this behavior. Upon carrying out some research on the web, I have come across the following two articles:
http://support.microsoft.com/kb/926098
http://blogs.msdn.com/b/distributedservices/archive/2009/06/19/tracing-in-com-and-complus.aspx
These two articles talk about how diagnostic logging can be enabled for COM+ components. However, I am not really sure if they will be of use to me , as i need to accurately pin point as to what is changing the identity of the COM+ component to INTERACTIVE USER.
The other major disadvantage with this logging is that the .etl files output are in a binary format and can only be decoded by contacting Microsoft with the help of so-called .tmf files.
Questions:
What are the other options available to me to diagnose this issue?
Can I format the .etl files without the help of Microsoft?
Is there any mechanism in place just like process monitor, which could monitor all the events within COM+?
I don't know if this will help or not but http://www.fileinfo.com/extension/etl says you can use tracerpt.exe (located in your system32/syswow64 directory) to produce reports from the etl files.
I have an ASP.net web app and on my test (database) server I have enabled sqlserver to store the viewstate and when I run the app from visual studio this works fine.
However when I try to host the app on the production machine (IIS 6) the viewstate is still present in each page request.
If I use the exact same connection settings against the production machine and run the web app from within visual studio the viewstate is not present.
This leads me to believe that theres either
1) Something I need to enable/disable in IIS
2) Something in my production web.config thats interfering.
If anyone can help me solve this problem it would be much appreciated.
Note Should add that I'm using Ironspeed to generate the pages. So there might be a configuration issue that ironspeed requires.
SOLVED It was an issue with Ironspeed which is a third party application for generating asp.net pages - a key was required in the web.config which was on my local machine but not in the production machine. Guess when you inherit another framework you also need to make sure you follow the framework requirements.
The first problem I see is with your question itself because 'session' and 'viewstate' are two entirely different things.
Viewstate will be there regardless what your session persistence mechanism is...
POST EDIT:
Good that you changed your question but there is not a native or built in method for persisting viewstate outside of the default behavior - which begs the question what method are you using?
Do you have <pages enableViewState="false" /> inside the system.web section of your web.config...? This should disable viewstate for all pages.
Make sure you understand the difference between Session and View State. They are similar, but separate concepts. You are storing your Session in SQLServer, but you still have View State enabled.
SOLVED It was an issue with Ironspeed which is a third party application for generating asp.net pages - a key was required in the web.config which was on my local machine but not in the production machine. Guess when you inherit another framework you also need to make sure you follow the framework requirements.
I'm working on a new feature for our product, a component of which has some fairly major security implications: it runs as a WCF service, and performs some highly-privileged actions. As such, I'd like that component to only be installed when the user requires it (and removed when it's no longer required), and for the installation to be accomplished programmatically.
I've looked into advertising (specifically, assigned installs), and it appears to be a good mechanism for accomplishing this. I'm not sure whether the installation of an advertised feature can be undone, however, which would be useful for removing the component when it's no longer required. I'm also not completely sure whether programmatic installation could be achieved with advertising: advertised COM classes seems to be discouraged.
I'm wondering, therefore, if a simple call out to msiexec to install/remove the component would be more sensible. The component could be packaged in a separate MSI, or as a separate feature of our main MSI.
What techniques have you used for installing features on demand?
I resolved this by installing all the necessary bits and pieces up front and then starting/disabling the WCF Service as required.