Here is my scenario:
I have 7 different webparts
In order to have more control over the projects I have split them in different projects
All of the projects were created using the Yeoman installer
All was fine until I started to add them to the pipeline. Then I realize that I need to make npm install for every project. This is causing delay in my build pipeline as well as disk space.
My question is:
How can different webpart solutions share single node_modules folder?
Regards, Dimitar
#JohnRambo,
A quick way is to create a Symbolic Link from a real node_modules folder to other projects.
mklink /d D:\shareablemodules\helloworld-webpart02\node_modules D:\shareablemodules\helloworld-webpart01\node_modules
More references:
https://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/mklink
BR
Related
Using TFS 2010 and I have a build project consisting of 2 solutions. One is a MVC solution with web pages the other is a solution containing multiple projects. These are various WFC services. I have added the criteria to publish each project in both solutions.
If I build either of them from VS - I get the zip files created.
If I use msbuild from a command prompt and build the WFC solution - I get the zip files.
Same for the MVC.
I then have a build project that builds both solutions, and I have as parameters
/p:DeployOnBuild=true;DeployTarget=Package
When I submit that build - it completes. But in the "_PublishedWebsites" folder I only get a package for the MVC project.
I've tried a LOT of variations but can't get the WFC solution to create the packages for the projects. I even named the pubxml files the same in each WFC project and tried passing that in as another parameter but the same results - MVC is correct; nothing for the WFC.
Even tried changes to Debug|AnyCPU versus Debug|Any CPU (space added).
I am thinking I have some little thing off that is biting me - but I can't find it.
Appreciate any assistance!
The WCF projects need to have been created as Web Applications and not just Websites. The default behavior you want is only available in Web Application.
There is walkthough on how to do the conversion on MSDN (http://msdn.microsoft.com/en-us/library/aa983476(v=vs.90).aspx). I tend to modify the documentation to be an in place upgrade by creating a blank web application and copying the project file over the top of the existing location.
You can then open that new project in VS (giving you two views of the same thing) and then adding the hidden files. Once working you can then delete the WebSite project and you will be left with thebWeb Application that will output to _PublishedWebsites.
I'm start to develop modules for DotNetNuke. I followed different tutorials(most by Chris Hammond) but there is something i don't like, and I'm searching a different way to do so.
He recommends to put a DotNetNuke installation, with IIS and SQL Server, on the developer PC and put your Project into the DesktopModules folder. I don't like it because i want to separate my project from DotNetNuke.
Is there a way to split the build/publish to different location like dll into folder x and all other stuff into folder y?
You could, but I don't really see the point. I see where you're coming from because it seemed awkward to me at first as well, but it really is the most efficient way to develop on the DNN platform. I have mine set up so all of my modules are in the same solution and branched in source from the root DNN folder. We don't keep the DNN core in source so the developer is responsible for that, although that may change at some point to keep versioning consistent.
By keeping your project located where it's installed, you can develop your modules the same way you'd develop any other web app you're building. If you make a change in markup you just have to save the file and refresh your page. If you change something in code just build and refresh.
If you really must keep them separate, you can absolutely do so (really the only benefit of this that I can see is that if you uninstall a module and accidentally click the checkbox to delete files - it happens - you don't have to worry about it). Create your project where you want it, change the Output Path to your DNN bin folder, and create post-build events to copy all of your .js, .ascx, and .css files (plus any others you may need - images, HTML files, XML files, etc.) to appropriate folder(s) in the DesktopModules folder. Just remember that you have to build the project every time you make ANY changes to test them, and you have to write/change your post-build events every time you add a new type of resource, change/add a directory, etc.
Either that or you can build an install package and uninstall/reinstall the module every time you change some padding in your stylesheet ... but I'd stick with keeping the project in the DesktopModules folder.
Sure you can do that.
Set up your solution and module projects anywhere, build the projects and copy the appropriate parts (such as the *.ascx , *.ascx.resx, *.dnn files) back to your website folder -
website/ DesktopModules/Your_module_name
Copy the module dll to the website's bin and you good to go.
I'm setting up an Orchard CMS project with the intention of creating a module to house my MVC 3 application. This application has already been started and has 5 projects already. One web project, some test projects and a workflow project.
Requiring that the web project (and therefore the other 4 projects for simplicity) lives within /Orchard.Web/Modules/ is a minor inconvenience - is it possible to change where Orchard looks (or add a new location) when dynamically loading the modules?
It's not a massive deal, but a nice to have for this project.
In an ideal world i'd be able to have:
/OrchardStuff/Orchard.Web
/OrchardStuff/etc
/MyStuff/MyProj.Web
/MyStuff/MyProj.Tests
I know i can arrange my sln in a nice usable way, would be nice if i could replicate this in the file system.
Cheers.
Wouldn't be easier to add an afterBuild task in your web project to copy the application to the Orchard's modules directory?
Something like that in the csproj file would do the trick (sort of, I am not entirely sure of my syntax. :'( )
<Target Name="AfterBuild">
<ItemGroup>
<AppFiles Include="**\*.*"/>
</ItemGroup>
<Copy SourceFiles="#(AppFiles)"
DestinationFiles="#(AppFiles->'..\OrchardStuff\Orchard.Web\Modules\MyModule\%(RecursiveDir)%(Filename)%(Extension)')" />
</Target>
The MSDN documentation is here: http://msdn.microsoft.com/en-us/library/3e54c37h.aspx
The solution I used is adding the following line to post-build operation:
if not exist "$(SolutionDir)..\Orchard\src\Orchard.Web\Modules\$(ProjectName)" mklink /D "$(SolutionDir)..\Orchard\src\Orchard.Web\Modules\$(ProjectName)" ""$(ProjectDir)"
This command creates a symlink of your dev folder inside Orchard's Modules folder (only if such symlink doesn't already exist).
It has the following advantages over #Eilistraee's answer:
If you change Javascript/CSS file in your dev machine, you don't need to build the project to get the changes into Orchard.
You don't get duplicate files on your drive
Post-build is a more explicit option and the macro variables make it easy to copy to any new module.
No that's not possible without some major efforts. Not worth it.
I'm using WSPBuilder and it is being very helpful. However, it was being hard to understand the strength of WSPBuilder because of missing manual. I've to create a solution file to deploy "Return of SmartPart" (.wsp file), "Application Template Core" (.wsp file) and also "AJAX Extensions" (.dll files). So, I won't have to edit the web.config to mark them safe controls. Please, suggest HOW?
Quick answer:
C:\Program Files\WSPBuilder\WSPBuilder.exe.config
(or where ever you've installed it)
add key="BuildSafeControls" value=""
Long answer:
WSPBuilder is great for when you want to do a quick deployment via Visual Studio to your SharePoint installation. I have found that that it gets harder to configure when you need to deploy CAS policies but I'm sure they will do work in this area for future versions.
WSPBuilder in your scenario can automatically build and deploy the safecontrol entries that need to go into your site. Good thing about WSP's are that once you retract a solution, it will also go back and remove the safecontrol entries so you don't need a tidy up job.
Regarding different projects, if you need to install third party wsps, then WSPBuilder hasn't been designed for that purpose, I suggest a simple batch file with some stsadm commands. If some of these solutions are your own code, you should divide each into a different VS project and build their WSP's seperately. You may even need to divide them into different .sln (solution files) but I've not tried this way myself so couldn't say for sure.
Personally, I would only use use WspBuilder to build deployment packages that need to be deployed to live environments if I can be sure its not adding extra bits that may become a problem. Therefore you'll need to think about WSPBuilder wsp's are good enough for you.
Recently I came accross an issue with CAS policies and decided to make my WSP's manually. Under the hood, WSP files are CAB files, you can just create a CAB file and rename its extention to .WSP. I would advise, creating a WSP, rename it to mysolution.cab. Open it and up and extract the files, and have a look to see whether its doing what you want. Key file to look at: manifest.xml.
As far as I know, you can't nest WSP files in other WSP files. You'll have to install those separately.
If you want to install DLLs (other than the one that's built as part of your WSPBuilder project), create a folder in the project called GAC and put them there. All DLLs in that folder will be installed to the GAC when the WSP is installed.
To install a WSP package, you'll need to run:
stsadm -o addsolution -filename MyFeature.wsp
You can then deploy it from SP Central Administration.
You can also create a WSP file manually without WSPBuilder - it's a CAB archive and you can create a WSP file using the makecab.exe utility that comes with Windows and an additional description file that lists the files that should end up in the WSP file.
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.