Orchard module not appearing in list of modules - model-view-controller

Downloaded the source code for an Orchard module from Codeplex and added using VS2012 to my copy of the Orchard source. When I run the source the new module is not available to enable.

It probably doesn't build. Check your logs, and if you still can't see what's wrong, attach a debugger.

Thanks Hazza and Bertrand - Fixed it by unzipping into the modules folder then added the existing project from the modules folder rather than from my download folder.

Related

How to add files into features in SharePoint solution

Actually in my project there are two .aspx files. I want to add them into two different features called feature1 and feature2. This is my project.
Is there any way to do this ? Thank You.
You should use Module for that ! With module you can add files to your WSP solution (and deploy this files to document Library)
And after, don't forget to add your module in your feature
How to: Include Files by Using a Module

qt jpeg images not showing on deployment (already added the plugins to the directory)

I am using Qt Creator 5.3 but any Jpeg images that I put into the build so not show up when I launch my exe. I got it working before by putting the necessary plugin dlls into the directory but now i still have this problem. In my research the only answer I found was to put the plugin dlls into the directory (which i already did) thank you.
add the image files to a resources file. It is very efficient and it is also cross platform. check out this link http://qt-project.org/doc/qt-4.8/designer-resources.html

Edit and package DNN module without solution file

I've recently been given a DotNetNuke module to edit and publish back to the website. However the module folder that I have been given is missing the visual studio solution file. It has all the individual cs files so I can open them up one by one but there is no overall file for the module, and so I'm not sure how I can then repackage and deploy the changes once I've completed them.
I have tried creating a blank solution to add the project to but I get an error when I try to do this that goes like:
Unable to read the project file '...csproj'. The imported project "....nuget\nuget.targets" was not found. Confirm that the path in the < Import > declaration is correct, and that the file exists on disk
Can anyone help?
Thanks
The module might have been built as a WSP type project where there is no compiled DLL and .NET just compiles the files in place. If you got a module package, you should be able to install the module into a DotNetNuke site, add the module to a page and then just make changes to the files within the App_Code and DesktopModules folders and refresh the page to see the changes.
When you're done, you can either just copy the updated files into the zip package or, you can go to Host -> Extensions. Then edit the module and from the Manage Menu select "Create Package" and it will generate a new Package.

How to use assemblies in a VS solution under source control and keep assemblies updated?

(I no longer want an answer. OML, my English has surely improved...)
How to use assemblies in a VS solution under source control and keep assemblies updated?
(Source control is provided by the codeplex and VS default options for it.)
I mean,I have a project named HyperAero.
I have another project named TestAnimation.
TestAnimation is under source control and needs hyperaero.
When I check in,HyperAero.DLL will not be saved in server.Of course,I can add hyperaero.dll to my solution as a file but I want it to stay updated with my changes in HyperAero project automatically.
What should i do?
Answer (Got it myself):
command:
robocopy "E:\Documents\My VS\Fix soft HyperAero Form\Fix soft HyperAero\bin\Release" "E:\Documents\My VS\Fix soft Animation Maker\Test of Animation Maker\DLLs" "*.DLL"
set rce=%errorlevel%
if not %rce%==1 exit %rce% else exit 0
Similar Question (Remember that i want my assemblies to stay updated):
When using custom assemblies in a visual studio project. How does one check in those assemblies in source control with the project so that anyone can download the project and build right away.
There are two way to approach this:
1/ Don't put the assembly dependencies in source control and always include in your solution their Visual Studio project instead. In your case you'd have a solution with the Hyperaero project and TestAnimation project with a project dependency to the Hyperaero project.
This way you don't have to put the generated DLL in source control and keep it updated each time you change something in the code.
2/ If you really want to dissociate both projects, then I'll recommend you to use Nuget and build a Nuget package for the Hyperaero project and then reference the Nuget Package in you TestAnimation project. This approach is the cleanest one, but it may be overkill and at last it's not something you'll setup quickly (compared to 1/).
Put both projects in the same solution and add a project reference.
Use your source control's UI / command-line to add the DLL files.
What source control software do you use?
If you are using subversion:
ankhsvn (Visual Studio plugin) can handle multipe repositories in one solution.
I have the following structure.
- App1\
App1.sln
App1Forms\
App1Forms.csprj
- App2\
App2Dll\
App2Dll.csprj
Now If I open App1.sln and add App2Dll, which is outside the folder structure, as a project, the project gets linked as a relative path. I am fine, if I check out both sources to the same parent directory.
Ankh is aware of that and If I hit update both projects gets updated.
If I want to commit changes I am only allowed to commit to one repository at a time, but again, ankh informs me about that.
Another way is to use svn-externals http://svnbook.red-bean.com/en/1.0/ch07s03.html
which will transparently include one repository inside another.

Where to put content, in Installer project (WiX) or in code project

So I see two solutions to my current problem, but I was wondering what the pros and cons are, or if there is a defacto best practices approach.
So my current project has a number of configuration files, help files, and other external content. I need this content local to run and debug the application. Currently we duplicate this content in a standard windows installer project. This clearly is a bad idea. We are moving to a new setup that uses the WiX installer, and I'm currently setting the project up next to the code project and trying to figure the best way to share resources. I see two solutions.
One is that I can put all the resources in the WiX project and then add them as links in the code project. This way I know what I'm debugging is installer.
The other option would be to leave the content in the code project and path into it in the installer using the reference variables.
Right now it seems 6 one way, half dozen the other. Any persuasive arguments for either method?
Assuming that these configuration and help files are going to be installed in the same directory as the executables then definitely put them in the code project, mark them as Content, and add a reference to the code project to the installer project. If you're using WiX 3.5 the files will be automatically included in the installer along with the executables, which makes writing simple installers much easier.
For earlier versions of WiX or more complex deployment scenarios (where the content files could be going into different directories) you would still put them in the code project but then you'd use File elements with a relative path or reference variable in the Source attribute to include the the content files from the code project directory.
I don't believe that putting the content files in the WiX installer project directory instead of the code project directory will do anything to ensure that the version you use to debug will be the same as the version installed. That can only be ensured by thinking through the process of how your application finds these content files and making sure the right versions are found.
So going back to the simple case where the content is in the code project and marked as Content, and it will be installed and loaded from the same directory as the executables, then it is only a matter of setting "Copy to Output Directory" to "Copy always" or "Copy if newer" and then you can be sure the versions used in debugging and the version installed will match.

Resources