I need to create the following structure in InstallShield (Basic MSI Project).
DefaultWebSite
-MyWebsite
--Entities\MyWebsite
--Entities\Workflow\MyWebsite
--Workflow\MyWebsite
Once again, the above structure is in IIS, after installation.
How do I replicate the above structure in InstallShield?
When trying to define a website like this "Entities\MyWebsite", the "'\" was removed as it is an incorrect character.
In Application Data ⇒ Files and Folders
you create the New Folders Entities, MyWebsite, etc.
Level by level, so the backslash is not part of the name.
Related
I'm following the tutorial here.
I created a new Web Application. I then added two Class Library projects, Common and Domain. The common project contains the SubSonic library while the Domain project contains the SubSonic .tt and .ttinclude files.
After modifying the settings in Settings.ttinclude, I try to 'Run custom tool' on the tt files and I get this error:
Running transformation: System.ArgumentNullException: Value cannot be null.
Parameter name: The project does not contain App.config or Web.config file.
I can provide the rest of the stack trace, but it appears that it can't find my Web.config which was the connection string. Adding an app.config to the Domain project just causes the generation step to complain about not finding expected sections.
Is there a way to have these files in a separate assembly but still use the web.config for settings?
You need to place an App.config in the project you want to generate from. Yes, it's redundant but there's no other way to handle this with T4
I have a .browser file that I need to deploy to the following location:
c:\browsers\
as part of a moss .wsp file. Can I do this in the manifest.xml or as part of a feature?
It is not possible. You can use the wsp solution to deploy any File to
Inside 12 Hive Folder Hierarchy
GAC
bin Folder of the Web Application.
Rest of the other location you need to look out for the custom solution. One option I can say is to use a Feature Installed event and keep it a Farm Feature.
I would like to add basic logging and make some other minor changes to the classes generated by SubSonic 2.1 (I'm not using SubSonic 3.0 t4 templates).
Is there a way to do this without modifying the SubSonic source code?
You have two choices. You can modify the default templates or create your own. I suggest making your own templates which will lives side-by-side with the original and then generate your code via the following instructions.
Note that these steps assume you ran the default SubSonic installation. In other words, Sonic.exe and the default templates can be found under c://program files/. If not, you'll find your SubSonic files/templates in an alternative installation location, of course.
Make a copy of the default templates folder as found in C:\Program Files\SubSonic\SubSonic 2.1 Final\src\SubSonic\CodeGeneration\Templates. I might recommend naming the copied folder "TemplatesWithLogging.”
Open the aspx files in Visual Studio and modify to your heart’s content. For example, I wanted an alternate C# class template so I modified CS_ClassTemplate.aspx. If you want to merely alter the default templates, you can but I suggest making a backup first.
I am going to assume you are already familiar with code generation with SubSonic. I personally like to setup a Visual Studio External Tool to allow for quick, pre-configured regeneration. Otherwise, the following can be ported over to the command line. Here’s the External Tool setup instructions:
Tools > External Tools > Add Title: TemplatesWithLogging
SubSonic Classes Command: C:\Program Files\SubSonic\SubSonic 2.1 Final\SubCommander\sonic.exe Arguments: generate /out Generated /namespace NAMESPACE /server SERVER/db DATABASE where NAMESPACE, SERVER and DATABASE are replaced accordingly.
Initial Directory: $(ProjectDir)
Check “Use Output window” and “Prompt for arguments.”
Select Apply or OK
4.Select the project which will contain the “Generated” folder and auto-generated files. Select Tool > TemplatesWithLogging.
You can find more here.
Yes you can modify the templates that version 2 uses, they're just aspx files. The templates are stored in src\SubSonic\CodeGeneration\Templates under your installation directory.
This blog post goes into more detail:
http://johnnycoder.com/blog/2008/06/09/custom-templates-with-subsonic/
I am working on a sharepoint feature which includes a couple of list definitions, 2 webparts, a feature receiver assembly and an InfoPath form.
I have to use WSPBuilder to package these, and the requirement is to package all these features into a single WSP solution file.
Now, WSP builder requires the deployment files in a particular folder structure, same as the 12 Hive of sharepoint.
My problem is that all my features were developed separately, and consist of multiple project files, and these are not necessarily in the same folder structure..
How do I use WSP Builder to package multiple features into a single WSP solution?
Maybe this will help: http://www.codeplex.com/wspbuilder/Thread/View.aspx?ThreadId=43125
Ultimately, I think you gain a lot of flexibility by building your own wsp files by using a tool like NANT.
There's no particular action you need to undertake in wspbuilder to have multiple features in the same solution package.
All you need to do is create a new folder for each feature under the 12\TEMPLATE\FEATURES folder inside your solution in Visual Studio and place the appropriate feature.xml file in that folder. For example, you may have:
12\TEMPLATE\FEATURES\FancyFeature\feature.xml
12\TEMPLATE\FEATURES\ReallyCoolFeature\feature.xml
... and so on.
Upon building the solution, wspbuilder will read the entire tree structure of your 12 folder and append the corresponding nodes in the wsp's manifest.xml file. The same goes for any other possible subfolders inside the "TEMPLATE" folder, including IMAGES, LAYOUTS, etc: at deployment time they will all be copied in the correct folder inside the real 12 hive, because the 12 folder inside your solution is meant to be a replica of the original one.
For a better understanding, create some folders and files inside your 12 folder in the visual studio solution, compile your project and look inside the generated manifest.xml file.
The simple answer is that you are going to have to copy all the files form the individual projects into one master project for your solution. As long as all your individual feature files are in the correct location in your '12' folder then you'll be good to go.
Note: You'll need to check all your references to any assemblies as this solution will create 1 assembly for all your custom logic.
I had trouble adding dlls to the wsp so I wrote a short article about it: How to Add DLLs to a WSP Solution
I usually have one project in the solution designated as the "main" one. I set the dependencies so that this "main" project is built last. Then for the other projects that I want to be included in the wsp package, I edit the "Post Build Events" to xcopy the contents of the 12 folder and that dlls built by the projects into corresponding folders for the main project. Then after I build the whole solution, I can build the wsp package for the main project and know that it contains everything.
What files can we modify so that our solution is still supported by Microsoft?
Is it allowed to customize error pages?
Can we modify the web.config files to use custom HTTPHandlers?
You can certainly edit the web.config file for your sites. The one thing that you should be aware of, however, is that when you start editing files manually on the file system, you will have to remember to manually make those changes across all servers in the farm (assuming a farm exists). In addition to this, when you edit files in the 12 hive, it's important to understand that you will be making a change to all SharePoint sites hosted on the server(s) for which the files were edited.
Personally, if I were going to create a custom error page, I would simply add a <customErrors> section to my web.config. I avoid editing any existing files in the 12 hive, but I have added files (though it's rare).
The customization of the error page is not very easy (or flexible). You can see an example here:
http://blogs.msdn.com/jingmeili/archive/2007/04/08/how-to-create-your-own-custom-404-error-page-and-handle-redirect-in-sharepoint-2007-moss.aspx
The web.config can be changed. I used my own HttpModules in addition to the original ones, but I haven't used custom HttpHandlers. IMO it should work if you don't change the original handler (i.e. if you add your handler for a specific type of file not handled by SP).
do not modify any pre-installed files in the 12 hive (Program Files\Common Files\Microsoft Shared\Web Server Extensions\12)... a service pack may update and overwrite any changes.
Anything in the Content Database (Masterpage, Stylesheets list in ~Catalogs) is available to modify (I would add, instead of update, in case a service pack changes anything) as it sits atop the file system, and is instantly available to any members of the web farm (newly added servers).
Any custom features, added to the 12 hive in the features folder, in a custom/non-microsoft folder (that is, inside the 12\feature folder, do not modify any preinstalled files, but feel free to add a folder for your feature and work within).
Custom features can be developed using the Visual Studio Extensions (VSeWSS), currently available for Visual Studio 2005/2008... benefit being that the output is a feature package (.WSP file) which is designed to be portable across SharePoint. Additionally, the .WSP files are just CAB files with a different extension, offering the ability to be explored by simply renaming them.
For site definitions, Microsoft has a good article about what is supported and unsupported. In short, the only change you can make to the out-of-the-box site definitions is changing the entry in the webtemp.xml file to hidden in order to prevent the site definition from appearing in the site template list. This is something many may be interested in doing.
You may also, of course, copy existing definitions and rename them in order to create new ones.
The complete list of supported and unsupported scenarios for working with custom site definitions can be found here:
http://support.microsoft.com/default.aspx?scid=kb;en-us;898631
Here is the closest I can find to a official response from Microsoft:
http://technet.microsoft.com/en-us/library/cc263010.aspx