I created a new webdesign project, and restarted the Designer, but it does not show when I try to change the web design project. I've checked it contains all the normal directories and files (navpoints, widgets, project.xml, properties.xml, etc). The log file says it's loaded, but when I click on the project name in the designer to change web design project, I see all the other projects but not this one.
If you have a extension project (under the devel directory) and a web design project (under the devel/webdesign directory, and they have the same name, the web design project will not be visible.
A common convention to prevent this is to append the suffix "_t" to the extension project name. For example, you might have the following directory locations:
devel/myproject_t
devel/webdesign/myproject
Keep in mind that these are independent of any github names used for these projects, which could follow this convention, but more commonly follow the convention of a "_webdesign" suffix for the web design project, but no suffix for the extension project.
Related
We have an internal JavaScript library that we'd like to share between multiple projects. Actually we are already sharing it via file copying, but this has (predictably) resulted in multiple forks of the code.
The consuming projects are a mix of "full" ASP.NET (MVC and Web Forms) and ASP.NET Core MVC. (I'm planning on creating two separate packages.)
Installing into ASP.NET projects seems to work fine, but I'm having problems with ASP.NET Core.
Initially I had all the artifacts within a files element, and nothing at all was showing up in the consuming project. After re-reading the docs, I realized that ASP.NET Core projects would use a PackageReference ... so I would have to use a contentFiles element instead of (or in addition to) a files element.
I created a contentFiles folder and a script to copy the requisite files from the source project folder structure into contentFiles/any/any/wwwroot/lib/ourAwesomeWidget, and modified the package manifest accordingly.
This works. Sort of. The package appears to get build correctly. The files do get added to the consuming project, but they get added as links; the actual files (the link targets) reside in my local package cache.
The relevant portion of the package manifest is:
<metadata minClientVersion="3.3">
...
<contentFiles>
<files include="**/*" buildAction="Content"
copyToOutput="true" flatten="false" />
</contentFiles>
</metadata>
<files>
<file src="contentFiles\**" target="contentFiles" />
</files>
Part of the issue is that I don't find the docs very clear concerning contentFiles. All the examples show a single file element ... but the include attribute on the files element is required, so it's not clear what the individual file elements would even do.
Is there a way to get the actual files (not links) added to the consuming project? Or, alternatively, is there a way to get the package to install as a "normal" package (rather than a PackageReference)?
Update:
I did some further digging and found this answer by #Martin to a similar question -- but he answered this one before I had a chance to update it.
It appears this behavior (adding files as links) is by design.
I find this highly unsatisfactory, because (as #Martin points out), our JavaScript library will not be available during development on consuming projects.
But part 2 of my question still stands. According to the docs,
By default, PackageReference is used for .NET Core projects, .NET Standard projects, and UWP projects targeting Windows 10 Build 15063 (Creators Update) and later.
Is there a way to trigger the non-default behavior, i.e. allow .NET Core projects to consume packages other than via PackageReference?
contentFiles are supposed to be added as a link. The contentFiles section controls the msbuild items that are generated for these files into the obj\projectname.csproj.nuget.g.props file.
The copyToOutput="true" will cause the items to be copied to the output and publish directory. However that does not help you when running the application during development, since it will be run from the project directory, not the output directory.
Consider consuming client libraries via npm (since bower is deprecated).
I am creating an application which will coordinate and organize a lot of standalone functions. For instance, the main application might be called ABC Company Operations, and within it might be Engineering Bills Of Material and Project Management Purchase Orders, among many others. I want to develop each of these tools as a standalone solution, then include them in the main application when I am done with them. For one thing this will allow me to distribute the main application with a fair number of tools complete, then issue an update when each new one is included, and for another thing having these functions in their own projects will cut down on the madness inside the solution explorer.
Searching and reading have shown me how to include existing projects in a solution, but they are included as a reference - the files continue to reside in the standalone solution. This is not good because I wish to make any changes needed in the standalone, then replace the project in the main solution when those changes are done and also because I would prefer not to have all these solutions hanging around in a public place.
I tried just copying and pasting the project directory from the standalone solution into the main solution, but the solution explorer hasn't picked it up and there are somehow two listings of the standalone in the main Visual Studio screen where you select which solution you will work on. This seems like a bad road, so before I continue down it I would like to ask for any advice you folk may have.
Visual Studio allows you to reference the same project in different solutions.
Right click the solution in the solution explorer > Add > Existing Project...
I have done it and it works perfectly.
But very often referencing the DLL of a class library project is just enough. Usually you would reference the bin\Release version. You can even reference an EXE.
I achieve something like what you want by using the Subversion code management system. I keep each project in a directory. These are top-level directories in the Subversion repository.
Each solution is also a top-level entry in the Subversion repository, but does not have any projects in with it. So I have in my repository something like this:-
project directory
project
files directory
files
project directory
project
files directory
files
single-project-solution directory
single-project solution
single-project-solution directory
single-project-solution
multiple-project solution directory
multiple-project solution
I then use svn:externals to include all the needful project directories when either a single project solution or a multiple project solution is checked out, and it ends up in the working copy like this:-
multiple-project solution directory
multiple-project solution
project directory
project
files directory
files
project directory
project
files directory
files
or
single-project-solution directory
single-project-solution
project directory
project
files directory
files
I have been searching around for an answer to this question, but I cannot find the documentation on it. I found a few similar questions asked here, but none that completely cover it?
Similar Question
What do all of the different files in the project directory do? I am trying to make my project open source and I don't want to have a ton of unnecessary files in my repository. What files are vital and what files will be generated when the user initially loads the project? Its important to note that this is a VB Form Application
Base Directory:
*.vb
*.Designer.vb
*.resx
*.vbproj
*.sln
*.vbproj.user
*.config
Any of the other folders in the base directory?
*/bin
*/Collection
*/My Project
*/obj
*/Resources
*.suo and *.user files can be ignored. They store user specific settings such as window arrangements, open files etc. Those files are generated by Visual Studio whenever a solution is opened.
*.vb files are somewhat important since they contain your source code...
*.sln and *.vbproj files tell Visual Studio which projects are in a solution and which files are in a project, respectively. They also contain project specific settings such as build plattforms, custom build events, target .NET Framework etc.
*.resx and app.config can be important, depending on your project. They should not be left out when you publish your project, however since they're part of the Visual Studio project. If they're truly not needed you can remove them from the project.
Edit
Folders bin and obj are where Visual Studio generates the compiled output so you should not include those when you publish the source code of your project. Any other folders are project specific so it depends on your project if they're needed or not.
As a rule of thumb, anything that is automatically generated should be excluded when you publish your source code.
Also, if you don't already, you should use a version control system such as Subversion or GIT to manage your sources. Any essential files / folders as explained above should go in there.
This pertains to Web Deploy and/or Web Deployment Projects (not sure what the relation is between those). Simply curious about the constituent Tasks that I might be able to recompose into a customized package Target.
The publishing targets for generating msdeploy web packages can be located at :
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
In addition to playing with the tasks, there are a variety of properties you can use to redirect the packaging output name, location and configuration....
When creating a project with the webapp archetype in Maven, they subtly advise not putting any Java source in the webapp project by not including the "src/main/java" folder.
What do you name your Maven projects?
project-webapp for the project that contains the JSP, CSS, Images, etc.
project for the project that contains domain specific entities
? for the project that contains the web application files like Servlets, Listeners, etc.
My first inclination would be to use "webapp" for the project containing the web application files (Servlets/Listeners), however the archetype uses "webapp" to convey the JSP/CSS/Images project and would cause confusion to other developers.
When creating a project with the webapp archetype in Maven, they subtly advise not putting any Java source in the webapp project by not including the "src/main/java" folder.
That's not really true. When you create a project with the maven-archetype-quickstart, you don't get a src/main/resources directory. Would that mean you should not put resources in this project? No.
What do you name your Maven projects?
There is no general rules, nor conventions. Use something that makes sense for your organization and your team. But as I said above, your initial assumption is not true and putting Java code inside a maven war module is a common practice (except for code you want to share between modules).
Not sure if this below link directly answers your question, but it makes sense to refer it
Refer their JIRA task here Document the naming convention for archetypes
As per this, the naming convention can be as below
The Artifact id of the archetype should be of the format -archetype-
Ex: + maven-archetype-quickstart : Which indicates the archetype is from maven and the project is a quick start
Same way you scala-archetype-simple : Which indicates it is from scala and is a simple scala project
Best of luck