Some time back, I created two separate SharePoint projects in VS 2008; one using STSDEV, the other using VSeWSS 3.0. I want both of these projects to be created with VS extensions, but how can I tell them apart? The project files look very similar...
Inside the .csproj file (or .vbproj, heaven-forbid) you'll find a <ProjectGuids> tag or something very similar. Their should be a guid in that element unique to each project type.
-Oisin
Output in both seems to be the same so the simple answer seems to be re-create both in VSeWSS 1.3
Related
I have a Liferay 6.1 instance with a custom classic theme, but trying to upgrade it to 7.0 is being so painful that I decided to take Liferay 7's classic theme (downloaded from here).
To bring it into Eclipse - Liferay IDE I created a new module (theme) project and imported files, but trying to deploy it was sending errors (for example, no init.ftl, stuff like that, unexpected given I am using the repo source).
When I arrived to this error, solved it and tried to deploy, it again said there's no init.ftl... Then I searched for it into the war and it actually wasn't there! No idea about what but... I noticed a portal_pop_up.ftl that doesn't exist in my source code!!! What is going on? I'm pretty confused.
Thanks!
Ok, the problem was with code downloaded from Github.
If you want to use classic-theme, just create an "empty" theme in the IDE and then overwrite it's files with the ones from auto"deployed" classic-theme in the L7 instance, in /opt/liferay/osgi/wabs.
I'd like to ask you for best practices with developing with Liferay SDK.
I have the SDK downloaded, I have Eclipse ready, it works, I can create new portlets and run local Liferay instance to test it.
Here is my situation - all the source code I have is in the Eclipse workspace, currently it is only portlets what I'm working on.
Liferay SDK I have in completely different location than workspace. Let's say ~/dev/liferay_sdk.
Eclipse workspace is located in ~/workspace.
At the beggining, it was not working like that. Eclipse from some reason can't find or use Liferay SDK. When I changed "Project validation" in Eclipse/Liferay configuration to "Ignore" the "Liferay Plugin SDK is not valid", it started to work without problems.
Next problem happend when it comes to need to build a WAR for example.
In the portlet directory in the workspace is present "build.xml" file. But inside it refers to another xml file, which should be located one directory up, and this one refers to more thing in relatively location and so on.
In short, it assumes that you have the portlets etc, inside the Liferay SDK.
Like "~/dev/liferay_sdk/portlets".
My question is, Am I wrong completely, or could you suggest me the best practices with this?
I don't want to mix SDK and the code, it sounds wrong to me.
Thanks for help!
I think, the best practice is still when your portlet projects are located inside the Liferay Plugins SDK directory. That way you can take all the advantages of the Liferay IDE plugin for Eclipse, for example. Because as far as I understand Liferay IDE will not allowed you to have portlet projects in another location. It's pretty easy to import projects to Eclipse from inside the Liferay SDK directory, and that's not problem.
But I also faced the same sort of problem when tried to save portlet project to the Git repository. Possible solutions with symbolic links didn't work correctly on every system. Thus I slightly modified the build.xml file to be able to run ant tasks from any directory. For portlets it was something like that:
<project name="your-portlet" basedir="." default="deploy">
<property file="build.properties" />
<property name="project.dir" value="${liferay.sdk.home}" />
<import file="${project.dir}/build-common-plugin.xml" />
</project>
Notice that you should define property "liferay.sdk.home" in build.properties and it should be path to the Liferay Plugins SDK.
As for other types of Liferay plugins (themes, hooks, etc.) you should import another build file for building that type of plugin. For example, for themes it will be:
<import file="${project.dir}/themes/build-common-theme.xml" />
Hope you'll get the idea. :) But think twice before doing something like that.
Liferay plugins are developed inside the Liferay Plugins SDK, its called SDK for a very good reason.
I don't find anything wrong with the plugins-SDK and the code tied togather, below are few reasons why:
If you see the liferay repository of plugins on github, you would find all the sample portlets and other plugins are stored in their respective folders inside plugins-SDK.
So if you want to develop liferay plugins (with or without IDE), the best practice (the only efficient way I think) is to have the projects created inside the respective folders of plugins SDK like portlet projects inside portlets folder, hook project inside hooks folder etc.
If you have used Liferay IDE when you create a plugin project (Liferay project) in this IDE you specify the SDK and the server runtime and what it does is it creates the project inside your Plugins SDK and copies the .settings, .classpath & .project file inside the project created. It does not create the project inside your workspace as eclipse normally does for other projects.
Hope I have managed explain it clearly and this was what you wanted.
I'm already quite happy with the other answers, this could have been distributed through comments at those, but a separate answer gives some more structuring options:
As Prakash says, it's not really bad to do that. In addition to his answer, you do not need to have your code in the workspace directory. Eclipse is happy to put it anywhere in the filesystem - thus while you work with Eclipse you don't even care where exactly your code is (and as you check it into version control - right? - you actually never need to care.
If you want to use Liferay's OOTB ant scripts: They are geared towards exactly the setup you describe: Work in the SDK directory. It's actually not bad, but if you don't like it, you just have to accept that you can't work with build.xml without changing it (like Artem suggests).
Another option is to use maven - this also bypasses the sdk (and the Liferay IDE integration), so you're again free to put your sourcecode whereever you like and let maven do the rest.
I can imagine some rather esoteric and rare issues with Artem's suggestion (like referring to custom parent themes when you imply some relative position) but I consider that as extremely minor, so if that works for you: Go ahead. Just keep in mind that you don't fulfill the basic assumptions that the SDK makes, so you might have to change things that violate the assumptions. I can't imagine this being too hard if you keep this in mind.
Of course, what you miss with that solution is the neat handling of including build.${username}.properties - you'll have to have your own build.properties that define ${liferay.sdk.home}. If you're not working in a team, that's ok. Otherwise you'll have to invent this yourself (and code it) or rely on global parameters to be configured with every team member.
This might be a dumb question, but I just integrated Subsonic to an ASP.NET 4.0 WebForms project and while the dll reference was added, I don't see the T4 templates anywhere.
I think that the T4 templates are not required if you're using the SimpleRepository approach, but I don't really see the sense in making Subsonic a NuGet package if you're not getting the T4 templates with it. I'd think it'd be rather more logical if the Subsonic NuGet package installed the T4 templates and the user just removes them if he doesn't need them, rather than having to download the T4 templates separately even though you installed Subsonic through NuGet.
Does anyone know anything about this?
I wanted to add them in but the problem is (according to David Ebbo) that the reference drops right into the /bin folder. The T4s, however, need to go into the root somewhere because you need to add the code to the project.
I know it's an inconvenience - but there was no manifesting system (not sure if there is one now) to use that would say "push this into the root".
If it changes, I'll update the package :).
Please note. Before anyone tells me about how I should compile the code for performance etc... this is just for a personal project and I want to be able to edit the code in a regular text editor and then it just works.
I usually code in C#, but this would be VB:
I have three files in a Virtual Directory
test.aspx
test.aspx.vb
web.config
I have copied the .Net 3.5 web.config line for line from a File > New Project.
It's not recognizing the XDocument class. Says, it's not defined Since this is a .Net 3.5 class, I figure it has to do with .Net 3.5
So, here's the question: Is this even possible to run a single page without compiling? Asp.Net should compile on the fly. It works with 2.0. Is there something I'm missing?
Just add the assemblies to the web.config file (sorry cant recall the exact place to put it, but a normal VS generated one should have a few entries already).
I am trying to make changes to a site that uses SubSonic 2.0.3. I have all of the code but I need to regenerate some database tables. I do not have the SubCommander exe though. I looked for an archive location but I can not find it.
Is there a way to get the SubCommander of this version. I really don't have the time to change every page to use the latest version.
-thanks
If you still have a copy of the *.aspx template files, newer builds from SubSonic 2 should do the same work for you since subcommander just takes the templates and generates some classes.
You can grab SubSonic 2.1 from here: http://github.com/subsonic/SubSonic-2.0/downloads
You should give it a try.
If you can't find the templates you could use a resource editor like this http://www.codeproject.com/KB/dotnet/asmex.aspx and extract them since they are part of the subsonic.dll
A bit late - but if you still need it -> https://dl.dropbox.com/u/5853240/SubSonic%202.0.3.zip