I'm creating a Nuget Package with a sort of basic CMS written in MVC5 that I can re-use across multiple projects. This CMS contains a resx file which, in order to be "Public", has the Build Action property set to "Embedded Resource".
Now, the problem is that when I install the Nuget Package in a project, it physically copies the .resx file in the App_GlobalResources folder (and that's correct, I want it that way so I can edit it) but the same resource is also built in the DLL (because of the "Embedded Resource" setting).
This, of course, creates problems and conflicts. But I have no idea how to fix this. The ideal scenario for me would be to use the resource without embedding it in the dll, but I saw that if I do that the resource can't be access from other projects of the solution (it's not "Public").
Any idea?
Related
My ASP.Net Core MVC project consists of 3 website projects, plus associated unit test projects, all collected in a single solution. Each of the website projects relies on common stuff, such as JavaScript libraries (under wwwroot/js/...) and views (under views/...). Is there some feature that lets me package up these files (none of which, as far as I know, can live in a NetStandard library project) and "install" them in all of my website projects so I only need to maintain them in a single place?
A razor class library (RCL) almost does what I want to do, but I want to be able to reference my JavaScript library from views in all three website projects. I also want the bundler/minimizer to be able to find my common JavaScript and CSS files. As far as I can tell, RCL only allows the Razor Pages in the RCL to access the static content (things like my JavaScript and CSS files) in the RCL.
EDIT:
After more thought, I've come to the conclusion that what I'm asking for simply can't be done "out of the box". In order to work correctly, the debugger and the bundler/minimizer need to find js and css files in the project's directory tree. What I'm asking for is a way to have something like a "reference project" that contains these "shared" files. I'm thinking that it's time for the "science project" approach: I'll create a reference project that contains the shared files, and run some code (at build time? via MSBuild? via unit test code?) that updates the files in the project from the reference project if they don't match.
FWIW, here's what I wound up doing:
In my 3 website projects, I have common files in several places:
Views/Shared
wwwroot/js/MyJsLibrary
wwwroot/css/MyCssLibrary
I created a "reference" project that contains copies of the common files in these folders. Then I created a unit test that simply verifies that the files in the "reference" project exist and are identical to files in each of the 3 websites.
No automated magic to keep the folders in sync. If someone changes one of the common files then the unit tests will fail until someone copies the updated file to the website projects and to the "reference" project.
We have an internal NuGet Package that consists of some .NET Code and a TypeScript Definition File (*.d.ts). This is the content of the package:
After installing the package into a new .NET Core project, the folder structure in the solution explorer looks like this.
So far, everything went as expected. But note the small arrow symbols on the "i18n" folder and the "Index.d.ts" file. It looks like they're just links to the actual file. When I click on the d.ts file the content seems correct. But Visual Studio fails to recognize the declarations in it, so I can't use it in my TypeScripts.
One idea was to include the path to the packages in the tsconfig.json, but that can't be the solution... Any other ideas how to do that?
How to add TypeScript Definitions to .NET Core Nuget Packages
As far as I know, Definitely Typed packages are not compatible with .NET Core projects. That because the script files should be included in <contentFiles> element. You can refer to the Including content files for more detail info.
Besides, just as Martin comment, npm is the recommended method of installing Definitely Typed packages:
https://github.com/DefinitelyTyped/DefinitelyTyped#how-do-i-get-them
So, after seeing the replies here and not giving up, I have to put in my approach to this.
As I'm working on a large solution with over 100 subprojects - many of them fast moving NuGets, I couldn't give up. I wanted to have my .NET object models including their interface/class representations in TS, being able to have both imported by including one NuGet (and thereby reduce dependency hell a little bit). I have to mention, I tested this only with my own object model, which has no external dependencies - and I tested only on VS2022.
But in this restricted scenario it works without any issues.
On the project containing the TS definitions
Set the build action for the ts definitions you need to be included in the NuGet to "content". This will include them into the NuGet package.
On the consumer side
Adjust your package reference, add the following property/value:
<GeneratePathProperty>True</GeneratePathProperty>
This will create an MsBuild property/variable referencing the path to the local presence of the restored NuGet file (important if your building on multiple, different machines - like on CI pipelines, build servers etc.) and allowing you to avoid any hardcoded absolute paths.
The generated property has the following format
$(Pkg<PackageNameWithDotsBeingReplacedByUnderlines>)
So a package named "MyPackage.Hello" would result in the variable $(PkgMyPackage_Hello)
Now we create a new build target to copy the files from the restored package's contentfiles folder (as it's restored, and we have the restored and thereby extracted path, we can finally target them).
<Target Name="CopyImportedTypes" BeforeTargets="Build">
<ItemGroup>
<TsTypesToCopy Include="$(PkgMyPackage_Hello)\contentFiles\any\net6.0-windows10.0.20348\*.ts" />
</ItemGroup>
<Copy SourceFiles="#(TsTypesToCopy)" DestinationFolder="$(MSBuildProjectDirectory)\AnyProjectSubFolderIfDesired" SkipUnchangedFiles="true" OverwriteReadOnlyFiles="true" />
</Target>
Make sure to adjust the "Include" path to your package (TFM, Platform etc.). An easy way to get the relative path is to open up the solution explorer, expand your consuming project, expand dependencies and then packages, expand the package with your ts definitions and open up the properties of the contentfiles.
This target is being executed before the actual build (so we can use the imported types on the build being happening right this moment) (BeforeTargets property). The ItemGroup is nothing else than a definition of items (in our case, source files) we want to use, being stored into #(TsTypesToCopy) which is being used by the copy task.
Thankfully, VS does automatically set new files to the right build action (in most cases), so the brand new ts files should be in the right mode automatically - so we don't have to tweak anything manually.
I want a custom directory structure for my Content in my MVC project for example:
\Content
--\js
--\css
--\img
Is it possible to tell a NuGet package to install scripts in the Content\js folder? For example the jQuery package so that the jquery-1.6.js file is installed in the Content\js folder?
A workaround is to use the Nuget Package Explorer and download the package you want into that. You can then edit the folders within the package using Package Explorer to suit your taste and save it into your own Nuget repository. This can be a file system folder or you can get more sophisticated here: Hosting Your Own NuGet Feeds.
Of course this means that you have to keep the packages in your private repository up to date. Clearly if you have a lot of packages to deal with this could become a problem. However it seems quite likely that a future release of Nuget will deal with the issue of local feeds because it's an issue for companies that 'restrict which third-party libraries their developers may use' as mentioned in the Hosting your own NuGet feeds reference above.
I believe the answer to that is "No." There are, however, some references to be able to set the root folder NuGet installs things into: http://nuget.codeplex.com/workitem/215 (see the comments)
How jQuery gets installed is determined by the package producer, which is the jQuery team in your case.
Where the jQuery package gets installed is up to you.
However, the where can only be adjusted in terms of the location of the installed package ($(SolutionDir)\packages folder is the default), and the target project where you install it into. From then on, the package producer takes over and decides where each piece of the package content ends up.
There are some good conventions for ASP.NET MVC, such as a Content folder, a Scripts folder, an App_Start folder (for WebActivator), etc. Think about the risks and extra effort involved of trying to move away from these conventions. Do they outweigh the benefits?
Now if you really want to use your own conventions, you could create your own package with your desired content structure and put the jQuery scripts where you want them in the consuming projects.
This means you would be using your own package with that specific version of jQuery. You just have to be careful to respect the licensing policy of the original package, and not to break any specific installation steps or requirements from the original package, which is fairly easy to do if you manually start changing package structure.
The answer to this is "no" because the "Content" folder is one of the Nuget's convention folders. However, if you rename your Content folder to, for instance, public and then have Nuget pack your public/js folder then when you bring the package in it will extract the files to the public/js folder.
Since I started to use Nuget I switched to using public for my public content instead of Content and rather use Content for files that I want to bring in untouched like source files (see here one usage of Content).
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.
We have developed a library in C#, and now I wish to create a project template to aid in using the library correctly.
I want new projects to include a reference to the library assembly, but would prefer not to have to deploy the assembly to the GAC, or to depend on the assembly residing in some specific location.
What I am thinking is to include the .dll in the project template .zip file. That means it will end up somewhere inside the project folder of new projects. Perhaps in a folder named Lib. Then the reference hint in the project file can point to that folder. Is that a good idea? What problems might I face down the road?
Is there perhaps some mechanism for including such 3rd party libraries in project templates that I'm not aware of? How have you tackled this? Surely I'm not the first.
I have had to address this issue in the past. In one case, it was a logging library that was installed to the GAC, which meant the Reference element simply needed the assembly name. In another case, we installed the library to the file system, created a registry key that contained the location (in case the user got cute and changed the install location on us) and used a project template wizard to look up the registry key and populate a replacement item to have the correct location in the Reference's HintPath. (Note: the template wizard approach requires you to install your wizard's assembly to the GAC, which it sounds like you're trying to avoid...)
If you don't want your library to be installed in either the GAC or a specific location, the approach of including the assembly in the project is pretty much your only remaining option. On the positive side, deployment of your project template is fairly straightforward and you don't have to muck with the GAC, custom wizards, etc. On the negative side, if you ever create a new revision of your library, your users will need to update every project's copy of the library.