I have created a DNN module using the Visual Studio template. I have the same module that works with several DNN carts. When I make changes in the core project, I want those changes to appear in the projects beneath it:
Core
ReleaseNotes.txt
Smith Cart
ReleaseNotes.txt (linked file)
Revindex
ReleaseNotes.txt (linked file)
I added the file by right clicking add existing item > add > linked file. When I try to install a module with the linked file, I receive an error that the ReleaseNotes.txt cannot be found.
Can I not use linked files in a DNN module?
Are you using my templates? (http://christoctemplate.codeplex.com) If so, you will likely need to modify the modulepackage.targets file to handle retrieval of the linked files. It is likely that the build script process doesn't know anything about the linked file and can't find it for packing.
I've not dealt with Linked Files before, so I really don't know what all will be involved.
Updated:
You might check out the last reply to this post on adding a new target
http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/6115f496-9e63-43e9-8642-2e0b3f413429/
Related
In VS 2017, or more accurately, the old project format used in VS 2017, each project had a 'Properties' folder with an AssemblyInfo.cs file which held things like project version, copyright, etc.
If you wanted to share some of that information between several projects, say all those in a particular solution, you created a AssemblyInfo_Shared.cs file, moved the shared properties into it, removing them from the original AssemblyInfo.cs file, then you would 'link' the shared version into each separate project.
Now when you build, information that is in AssemblyInfo_Shared.cs will be shared between all projects where as project-specific values would remain in the original AssemblyInfo.cs file.
However, in the new project format, these values are all embedded into the project's file, which now is a simple XML file. How can you share settings between projects now?
Properties (and even items) in the project file are processed by MSBuild, and can easily be refactored into .props and .targets files that are shared among your projects.
With the new project file format, MSBuild will automatically import files named Directory.Build.props at the beginning of your project, and Directory.Build.targets at the end - this includes searching up the folder tree until one of these is found. With this, it is very easy to share properties across all projects in your solution: simply create a Directory.Build.props file in the solution folder with your version properties, and every project will share those properties.
I have a solution in VS 2015 which makes use of multiple similar projects.
I added two new ones from a provided template and now building the entire solution shows two linker errors on those two projects.
I have compared configuration with other similar projects within the solution and everything was exactly the same. Building the projects one by one is successful.
At the Linker properties-> Input-> Additional dependencies I have the following libraries, created from other projects within the solution:
CommonLib.lib;UsermodeLibrary.lib
And the linker error I get is either:
Error LNK1181 cannot open input file 'CommonLib.lib' ProjectName
Or:
Error LNK1181 cannot open input file 'UsermodeLibrary.lib' ProjectName
I put the projects in the same folder as the others, and the solution makes use of filters.
My lab teacher figured this out for me.
For the sake of the answer let's call the new project I added from template "MyProject".
"You have to go the properties of the solution (right click on the solution -> Properties), there you go in the left tab to Common Properties\Project Dependencies.
After that you choose at the middle top of your projects (ex.: MyProject) and in the bottom window, you have to search for UsermodeLibrary and check/select it as a dependency for the project.
The thing is that every project is configured OK in the Project Properties (linker related and the rest), the only problem is that when you are building the solution it has to know per solution that some projects depend on other projects.
Here the dependency hierarchy is the following:
MyProject -> UsermodeLibrary -> CommonLib (-> means "depends on").
That's why you are seeing that CommonLib can't be linked to the project because it is not built before those applications.
Somehow, your templates miss this setup in regard to the Solution in which they are created."
We are using TFS and the added .ruleset files now participates in the check-in process. However, does not make sense to check-in those files. Just ignore the file on the source control does not solve the problem because those files are added in the csproj structure as well. Is there a plan to keep those files in a folder outside the project structure? Why, when connected to the SonarQube server, the plugin just download those files at the analysis time?
Thanks
There is no way to keep .ruleset files outside the project structure, as the rule set is to meet specific project needs associated with code analysis. It sits in a project properties.
I'm having a pretty difficult time with my resources within the view pages.
The auto generated view.g.cs page keeps including old using statements and I can't get it to stop. I have about 12 views and it will only do it on the first one, but then I delete that file completely and it then adds them to the next view. I've tried recreating the views and but the first one with the generated file still fails. I then set the build option to none, cleaned, rebuilt, and back to page, and it still happens!
I've tried deleting the actual generated files in the obj folder but they just get created again and the first view in my list then screws up again.
Any way around this? I think I've exhausted my options other then recreating the project but I'd prefer not to do this. Any other way to fix the generated files?
Cheers.
Try right-clicking on the XAML file and "Run custom tool".
This should generate the new, up-to-date .q.cs files.
EDIT:
Also, make sure that your own XAML and code-behind file is correct. The best way to do this is to perform a recursive search for the old namespace in all the files . in project directory (most appropiate part of it, for example: com.company.product.OldNameOfFeature - search for OldNameOfFeature). If there are any XAML or code files you'll need to fix them.
EDIT 2
This search should be done using external application outside Visual Studio, for example TotalCommander.
How to search in TotalCommander:
Figured out the issue, I had two warnings that said the new namespace was declared twice in the same file... builds successfully.
Cheers.
If you downgraded from .NET Core 6 to .NET Core 3.1, you need to fix your .csproj file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
Remove the "<ImplicitUsings>enable</ImplicitUsings>" line.
It is possible to export settings from one project and import them in another.
However, it seems that only "include Paths" and "Symbols" can be moved to a new project this way.
Is there any reliable way to copy all settings? Particularly I would like to copy the linker settings for my embedded ARM project.
I do not want copy the settings manually, as this is something that will have to be done often by at bunch of people.
The easiest way I've discovered to duplicate the settings for a project is to use another workspace. It takes a few steps to set up but you should only need to do it once.
1. Start a 2nd copy of eclipse and select or create a new workspace.
2. Import your baseline code.
3. Rename the project to something generic like NewProject
4. If your project has files you don't want to be imported into new projects delete them. I find it helpful to keep a few (like main.cpp)
Now back to your original workspace.
1. File->Import->Existing Projects into Workspace Next button
2. Use Browse... to go to your newly created workspace and select NewProject.
3. Check the Copy projects into workspace checkbox.
4. If you have warnings about the project already existing try clicking the Refresh button and make sure you don't have a folder in the current workspace with the same name. [ You can delete a project but not remove it from the hard disk so you have to make sure the intended folder name is not in use. ]
5. Rename the project to your desired name.
6. Start coding...
All the toolchain settings, include paths and library paths should be intact. It seems like a lot of work, but once you do it once its not too bad (as long as you can keep duplicating that one project).
This can be done in simple steps. Useful if you do not want to create new workspaces.
Open the project in the workspace.
Click on project and copy.
On the project tab area, paste the project.
Eclipse asks for a name, rename it to a new project.
Click Ok.