I've been asked to build a website with Plone. I would also like to use git version control for this project. Ideally, I would have all the work I do stored in one directory -- my project directory -- which will also make version control simple. Can anyone point me to a resource that explains how to do this?
We keep our company project skeleton at https://github.com/niteoweb/niteoweb.skel.plone.
It has some of our internal specifics, but should be usable. At least as a point of reference.
Related
I've been trying to wrap my head around module development for DotNetNuke for the past day and I keep running into roadblocks. Prior to this, being the *NIX/OSX grognard that I am, I have managed to create a Skin and a few Widgets "The Hard Way" by creating the manifest file myself with a python script, coding everything in Textmate and using a Makefile to create the packages anytime I update it, then installing it onto a remote development site on some shared hosting. However, I want to try things the "DotNetNuke way", so I've been looking around for instructions now that I've got a Windows VM up and running.
From what I've found, this is what you're actually supposed to do:
Create a local dotnetnuke website.
When the dotnetnuke website has been created, go to Host -> Extensions -> Create Extension
Select Module and fill out all the forms.
Open up the website in Visual Studio.
Find your module in the <site>/DesktopModules and start hacking away at it
When you want to redistribute your package, go to Host -> Extensions -> Edit Module -> Create Package.
There are a couple of problems with this, however. I get as far as step 5, and for some reason I can't seem to find my module in DesktopModules. I have tried looking elsewhere in the directory tree for my test module and I can't find it anywhere. In addition, when I try editing a package, I can't see any "Create Package" button.
Any ideas where I'm going wrong? I'm using the absolute latest DotNetNuke as of this writing (5.6.0), by the way.
Update: Okay, feeling a little foolish I first have to create the module in Visual Studio, then create the module in the website and attach it to the manifest of my module. However, when I do this, my site blows up because it seems to assume that I'm using a company name of "YourCompany". Fine. I revert, delete the module and try again but creating my module with a namespace of my company name doesn't seem to change any "YourCompany" names, they're still all over the created files. What in the heck is going on here?
You need to do a search and replace in the entire project as well as the settings in the Projects settings. Also here is a link that may help link
Have a look in the project/solution properties under application make sure root namespace is not YourCompany
We're a small team starting to use TortiseSVN to manage our web projects.
I was just wondering what is the best way to manage web projects into Subversion.
As you know a web solution consists of the .sln file as well as all the .aspx files.
Well we noticed when we right click the solution and we select "Add selected projects to subversion". It prompts me to tell it where to store the .sln file. So I give it some path like svn://serverName/CIS/MyWebSiteProject. Cool it just placed the .sln file...so I thought to myself how is it going to store the .aspx files as well.
Within a second I got a second prompt, I thought cool it is prompting me for the .aspx pages. So I tried giving it the path svn://serverName/CIS/MyWebSiteProject/ASPX_Files, but it comes back with an error stating I cannot place this folder within this path. I actually have to go outside of the folder MyWebSiteProject.
Not good cause now I have 2 folders one with the .sln folder and the other with all the .aspx pages and these folders are sitting on:
(sln file):
svn://serverName/CIS/MyWebSiteProject
(aspx files):
svn://serverName/cis/myWebSitePages
This really is not ideal cause I am sitting on the root of CIS with 2 folders for really one solution. Now when I try to check the project out I have to check both folders out.
What makes this even worse is when I do check them out I try to open the .sln file and I get an error that it cannot find the corresponding .aspx files. This seems like too much work, is there an easier way or a recommended way of using tortisesvn/subversion with asp.net web projects ?
While I am sure you have TortoiseSVN installed, it sounds like you are using Ahnk or some other VS SCC plugin to add from within VS.
I would suggest not using the plugin to initally add the solution to SVN, but to use TortoiseSVN in Windows Explorer for your initial check in. This will add your solution directory in its original state.
From that point on, you should be able to use the SCC plugin from within VS without trouble.
EDIT
Ok, after your commment I realize that I was not fully understanding the problem.
If you are dealing with a single project, after you create your solution and project, select the solution in Solution Explorer, go to 'file>save solution as' and save the solution inside the directory where your project file is.
Close the solution and go out to Explorer and use Tortoise to add the directory to SVN. If you have multiple projects/sites, just pick one to hold the solution.
Does that make sense? and from that point you should have no problems with ahnk
The key to successfully using Visual Studio with any source control is to put the solution file in the same path as the rest of the project files.
Usually, I will do something like the following:
\Project\Project.sln
\Project\MainWebSite\*.* <-- All web site files (including .??proj here).
\Project\Library\*.*
Then, I manually put \Project\*.* into source control.
Other options exist, as for my recent projects, I have been using:
\Project\SolutionFiles\Project.sln
\Project\MainWebSite\*.*
\Project\Library\*.*
Again, I manually put \Project\*.* into source control.
I generally find that it is better to set up the repositories for my solutions and projects from within Tortoise SVN. Then use whatever VS plugin that you care for to manage the commits of your pages etc. This gives you a little more control and allows you to get your setup correct from the start.
Is it possible to exclude a folder in a web project from being published? We've got some documentation and scripts that included in a particular project folder, and are added to the project, but when I do a VS publish, I don't want them to go up to the production server.
I know they shouldn't be in the project, but I thought I'd find a workaround before I try to convince the owner to modify the way he's doing things.
Old question, but I found if I mark the folder as hidden in Windows Explorer, it doesn't show/publish in your solution.
This is good for example to stop original photoshop images being included in uploads which aren't used and are big. Anything more complex though you'll probably want to write your own publish tool.
This doesn't answer your question, exactly, but my feeling is that unless you are a single developer publishing to a server, you would be better off doing builds on a dedicated workstation or server using MSBuild (or some other building and deploying solution) directly (and thereby would be able to very granularly control what goes up to production). MSBuild can not only build, but using some extensions (including open source types), it can also deploy. Microsoft has a product called MSDeploy in beta, and that might be an even better choice, but having no experience with it, I cannot say for certain.
In our situation, we have a virtual workstation as a build box, and all we have to do is double click on the batch file that starts up an MSBuild project. It labels all code using VSS, gets latest version, builds the solution, and then deploys it to both servers. We deploy exactly what we want to deploy and nothing more. We're quite happy with it.
The only downside, if it could be considered a downside, is that at least one of us had to learn how to use MSBuild. VS itself uses MSBuild.
For the files you don't want to go, loop at the properties and set the 'Copy to Output Directory' to 'Do not copy'
This option is not available for directories, however.
Can you not exclude them from the project through visual studio to stop them being published. They will the still exist in the filesystem
The only way that you can do this to my knowledge would be to exclude it from the project, do the publish, then re-include it in the project. That can be an issue.
There are probably much better ways to solve this problem but when we publish a build for our dev servers, we'll run a batch file when the build is complete to remove the un-needed folders and web.configs (so we don't override the ones that are already deployed).
According to http://www.mahingupta.com/mahingupta/blog/post/2009/12/04/AspNet-website-Exclude-folder-from-compilation.aspx you can just give the folder the "hidden" attribute in windows explorer and it won't publish. I tested this and it works for me.
Seems like a straightforward solution for quick and dirty purposes, but I don't think it will carry through our version control (mercurial).
Select all the files that should not be published.
Go to Properties
Set
Build Action -> None
Have to repeat the process for each sub-directory.
I'm trying to make a setup program for an ASP.NET web site. I need to make sure the target machine has sqlxml installed.
I must verify the target machine has the software installed, and if not, launch a .msi file either before or after the main installation.
I'm a complete newbie with setup projects, so maybe this is obvious, but after several hours browsing the web I haven't found a satisfactory solution. I've been reading about WiX, etc. but I'm looking (if possible) for a simple solution.
Thank you both!
I understand an installer can't run another one. I was thinking in a functionality similar to Prerequisites (in project properties). There I can check a component and it will be automatically installed if it isn't. I don't need to do anything else. But, the most important thing for me is that the installation won't run if it's not needed.
I also tried the .msm solution, but I couldn't find any. Maybe I can make one myself? I haven't tried it yet though.
Unfortunately, you can't run one installer from another, since only one can be running at a time. You need to chain them together and run one after the other. Google "msi chaining". This is often the reason why products like Visual Studio use an external setup.exe which then runs the installers one after the other.
Looks like you need to 'chain' the installs http://objectmix.com/xml-soap/84668-installing-sqlxml-net-app.html
You can get the redist here http://www.microsoft.com/downloads/details.aspx?FamilyID=51D4A154-8E23-47D2-A033-764259CFB53B&displaylang=en
CAn you add this as a pre-req for your install?
What are you using to build the create the install?
Edit:
I had a look to see how you can check of the SQLXML is installed and come across this:
http://www.tech-archive.net/Archive/SQL-Server/microsoft.public.sqlserver.xml/2005-04/msg00110.html
The system I am on just now has the following key HKEY_CLASSES_ROOT \ SQLXMLX (note the X at the end), so you might need to do a bit more investigation in to what the actual key is.
I'm not familer with Visual Studio install authoring but if you can add an entry to the AppSearch and RegLocator tables you should be able to check for the existance of the registry key when the install starts. See here
http://msdn.microsoft.com/en-us/library/aa371564(VS.85).aspx
The Reglocator table gives you the option to set a property with a value from the registry if found. You can then use this in the condition on a custom action.
A lot to put together, but I hope it move you in the right direction.
Brent's answer is correct. I would just add that, sometimes, you can find a "merge module" for the bits you depend on. That's a .msm file. You can certainly include 1 or more of those in your .msi file. I have no idea whether a merge module is available for SQLXML. Sorry.
As part of improvements to our build process, we are currently debating whether we should have separate project/solution files on our CI production environment from our local development environments.
The reason this has come about is because of reference problems we experienced in our previous project. On a frequent basis people would mistakenly add a reference to an assembly in the wrong location, which would mean it would work okay on their local environment, but might break on someone else's or on the build machine.
Also, the reference paths are in the csproj.user files which means these must be committed to source control, so everyone has to share these same settings.
So we are thinking about having separate projects and solutions on our CI server, so that when we do a build it uses these projects rather than local development ones.
It has obvious drawbacks such as an overhead to maintaining these separate files and the associated process that would need to be defined and followed, but it has benefits in that we would be in more control over EXACTLY what happens in the production environment.
What I haven't been able to find is anything on this subject - can't believe we are the only people to think about this - so all thoughts are welcome.
I know it's anachronistic. But the single best way I've found to handle the references issue is to have a folder mapped to a drive letter such as R: and then all projects build into or copy output into that folder also. Then all references are R:\SomeFile.dll etc. This gets you around the problem that sometimes references are added by absolute path and sometimes they are added relatively. (there's something to do with "HintPath" which I can't really remember)
The nice thing then, is that you can still use the same solution files on your build server. Which to be honest is an absolute must as you lose the certainty that what is being built on the dev machine is the same as on the build server otherwise.
In our largest project (a system comprising of many applications) we have the following structure
/3rdPartyAssemblies /App1 /App2 /App3 /.....
All external assemblies are added to 3rdPartyAssemblies/Vendor/Version/...
We have a CoreBuild.sln file which acts as an MSBuild script for all of the assemblies that are shared to ensure building in dependancy order (ie, make sure App1.Interfaces is built before App2 as App2 has a reference to App1.Interfaces).
All inter-application references target the /bin folder (we don't use bin/debug and bin/release, just bin, this way the references remain the same and we just change the release configuration depending on the build target).
Cruise Control builds the core solution for any dependencies before building any other app, and because the 3rdPartAssemblies folder is present on the server we ensure developer machines and build server have the same development layout.
Usually, you would be creating Build projects/scripts in some form or another for your Production, and so putting together another Solution file doesn't come in the picture.
It would be easier to train everyone to use project references, and create a directory under the project file structure for external assembly references. This way everyone follows the same environment.
We have changed our project structure (making use of SVN Externals) where each project is now completely self-contained. That is, any references never go outwith the project directory (for example, if Project A references ASM X, then ASM X exists within a subfolder of ProjectA)
I suspect that this should go some way towards helping solve some of our problems, but I can still see some advantages of having more control over the build projects.
#David - believe it or not this is what we actually have just now, and yet it's still causing us problems!
We're making some changes though, which are forced upon us due to moving to TeamCity and multiple build agents - so we can't have references to directories outwith the current project, as I've mentioned in my previous answer.
Look at the Externals section of this link to see what I mean - http://www.dummzeuch.de/delphi/subversion/english.html
I would strongly recommend against this.
Reference paths aren't only stored in the .user file. A hint path is stored in the project file itself. You should never have to check a .user file into source control.
Let there be one set of (okay, possibly versioned) solution/project files which all developers use, and the Release configurations of which are what you're ultimately building in production. Having separate project files is going to cause confusion down the road, when some project setting is tweaked, not carried across, and slipped into production.
You might also check this out:
http://www.objectsharp.com/cs/blogs/barry/archive/2004/10/29/988.aspx
http://bytes.com/forum/thread268546.html