I am working on Win 10 upgrade activity. As you know we can select application for file extension. So, those file will open on that app. e.g. html files only open in Chrome when user double click on that.
We can create XML file (DefaultAppAssociations.xml) and place it in C:\windows\system32
Now, I got the request to make one application default but let user decide if they want any other app. Is there any way to handle such things because defaultappassociations.xml will hard code this. Every time machine restart and it will set the same.
This is only possible as part of the operating system deployment or rather for newly created user profiles.
The command (official documentation):
Dism.exe /online /Import-DefaultAppAssociations:<path to exported xml>
However as I said you cannot alter existing profiles that way. Altering existing profiles in any way that is not the force via gpo is afaik not possible anymore because Microsoft does not want to allow it. A pretty stupid decision but at least you can tell whoever made the request that it is by MS design.
I am authoring an installer that creates a new website and application pool. This installer is for internal use within several development environments which all have subtle differences. One may use only HTTP, another only HTTPS and one might use both. One might use the default ApplicationPoolIdentity identity where as another may use an explicit User reference.
Given the association of a WebAppPool is by ID through a WebApplication which must be nested under a WebSite, each time an option is desired on the installer, the breakout and duplication of features gets ridiculous.
I imagine I am not the first to encounter this, how does one accomplish this much flexibility within an installer?
The route I went with was creating a basic template within WIX using expected IDs, then used an immediate custom action scheduled before InstallValidate which manipulated the template entries to what ever degree was required. The properties used by the CA to make the decisions are stored in the registry for modify/patch/removal invocations.
I am trying to give my users the ability to select the drive they want to load our software to. Instead of just giving them the InstallChangeFolder dialog I am attempting to just list the drives that are available to load on. I have done this in an InstallScript project before but now we are trying to move to MSI. Basically the flow will be they select the drive and then we append our root path to that drive. Does anyone know of any good tutorials that would explain how to create a custom dialog for changing the installdir and wiring up in all of the custom actions and sequences. If it matters I am using InstallShield 2013 and a Basic MSI Project
Why do you want to hardcode your installation path? That seems like enforcing bad design decisions on your customers.
The default method of allowing the user to pick the installation path is the standard method, for a good reason.
I agree hard coding the path is a bad design, however in order to achieve what you want just create new custom action by going through custom action wizard selecting installscript file, copy your code of install script and add place newly created custom action in the correct sequence.
What is the general feeling amongst developers regarding the changing of files in the 12 hive.
For example if you were asked to remove the sign is a different user menu item, you would need to modify the relevent user control on the filesystem. Now if you just go and modify it via notepad or copy over and then if you go and bring a new server into the farm you will need to remember to do the same on the new server.
Obvouisly you could deploy the changed file as a solution and have that done automatically, but I'm just wondering if people are hesitant to make changes to the default installed files?
I have done a bit of SharePoint development, and I must tell you that messing with the 12-hive is a ticket to a world of pain if you ever want to move the app.
I'd rather hack up some javascript to hide it, at least that can be bound to the master page, which is much more portable.
And remember, you never know when the next service pack comes around and nukes your changes :)
I agree with Lars. Sometimes you will not be able to avoid it, depending on your needs. But, in general the best policy is to avoid modification if at all possible.
I know that some of the other menu items in the current user menu (change login, my settings, etc) can be changed by removing permissions from the user. Under Users and Groups there is an option for permissions. I can't remember the exact setting (develop at work, not at home), but there are reasonable descriptions next to each of the 30+ permissions. Remove it and you start hiding menu options. No modifications to the 12-hive needed.
There is a very simple rule: if you want to keep official support from Microsoft, don't change any of the files in the 12 hive that are installed by SharePoint.
I've never encountered a situation where the only solution was to change such a file. For example if you want to change an out-of-the-box user control of SharePoint, you can do so by making use of the DelegateControl, and overriding it in a feature.
More info:
http://msdn.microsoft.com/en-us/library/ms463169.aspx
http://www.devx.com/enterprise/Article/36628
I know it's tempting to quickly change a file, and I have to admit sometimes I just do that on a DEV box, but don't go there on a production server!
Not sure if there is much use pitching in, as everyone else pretty much has it covered, but I would also say don't do it. As tempting as it is, its just impossible to know the full impact of that little change you have made.
From a support perspective you will make it difficult for Microsoft support (patches/hotfixes).
From a maintenance perspective you are also opening yourself up to long term costs.
Go the javascript route.
The way to go about it is to use a Sharepoint Solution (WSP) file.
To change the user control, create a new Sharepoint feature with the new functionality.
Include this feature in your solution.
Deploy the solution either using the stsadm command line, or through Central Site Admin.
This will then get automatically deployed to all the servers in your farm, and it avoids you overwriting anything default sharepoint files.
For more info, check out Sharepoint Nuts and Bolts blog on http://www.sharepointnutsandbolts.com/ which give an introduction to WSP and Sharepoint Features.
I've done this many times and I will speak from experience: Never ever touch the onet.xml files within the 12 hive under any circumstance. Any error that you make in there, and to make the CAML even more complex the file is largely whitespace sensitive, will have an impact on every part of SharePoint.
You should also consider that aside from the substantial risk to the installation, you may well be building in dependencies upon your changes that are then over-written in a future patch or service pack.
Most of the time, you can accomplish everything you want to using features and solution packages without modifying the files. However, there are a few (rather annoying) rare cases where your only option would be to modify a file on the system. I have used it for two particular cases so far. One was to add the PDF iFilter to the docicon.xml file, and the other was to add a theme to the themes.xml file. In both cases, it seemed to be the only way to achieve the goal. Still, we used a solution package to write those files out to all the servers in the farm.
Does anyone know if it is possible to display a prompt to a user/administrator when activating or installing a sharepoint feature?
I am writing a custom webpart and it is connecting to a separate database, I would like to allow the administrator to select or type in a connection string when installing the .wsp file or activating the feature.
I am looking inside the FeatureActivated event and thinking of using the SPWebConfigModification class to actually write the connection string to the web.config files in the farm.
I do not want to hand edit the web.configs or hard code the string into the DLL.
If you have other methods for handling connection strings inside sharepoint I would be interested in them as well.
Unfortunately there is no way to swap to a screen where you can get user via the feature activation process. Couple of comments for you:
I'm assuming the connection string is going to be different for every installation, so there is no way you can include it directly in the Solution.
I'm assuming that you couldn't programmatically construct this during installation.
Therefore, you need some way to get user input. Here are a couple of options:
It could be a web part property, though this would mean setting it each and every time the web part was added, and you would need to then maitain those settings individually.
You could build out your own _layouts settings screen (good post: http://community.zevenseas.com/Blogs/Robin/archive/2008/03/17/lcm-creating-custom-application-page-and-using-the-propertybag-more-detailed.aspx), and from there users can maintain the property, storing it in either the Web Property bag, or inside the Web.Config. I try to avoid using the Web.Config where I can, but if you do wish to go this route then MAKE SURE you use the SPWebConfigModification class (Read this great blog: http://www.crsw.com/mark/Lists/Posts/Post.aspx?ID=32)
Finally, a technique I often use is storing configuration information in a SharePoint List. Chris O'Brien has a great framework for that here: http://www.codeplex.com/SPConfigStore
Hope that helps,
Daniel
Sounds good. I will look at these possible solutions.
I do not think #1 will work since I am deploying multiple webparts inside a single solution which all use the same connectionString.
#3 sounds like a very clean solution. I see the config items are cached so it looks like if I need to store a connection string, I will not be hit with a SP lookup each time I need that string.
While searching for a solution I did stumble across another method.
If you dig around their code, I looks like they have created an installer that accepts application specific values, adds the values into a FeatureTemplate.xml file and passes them to the SPFeatureReceiverProperties object in the Reciever.
I was about to start tackling this method, but I think #3 would be better.
Thank you,
Keith