I have used Specflow/MSTest to create a test suite. I need to be able to package this so that a third party can run the tests etc.
I can use vstest.console.exe to execute the features/scenarios using a number of .runsettings I have.
Problem I have is how to copy the files from the Microsoft.TestPlatform nuget package to my project output folder (whether same folder, sibling folder whatever; that is not an issue, I can work that out no worries). I just can seem to work that out.
I have read a number of posts, on SO and elsewhere, with folk asking same/similar questions but I just cant repro how to do it.
Have tried editing the project file to copy PackageReference 'always', using the 'None' element etc but just can't seem to get it. Microsoft.TestPlatform is used extensively so I'm guessing that i'm missing something simple here; I just cant get Google to be my friend in this instance.
So, if my .NET5.0 (framework may be irrelevant) project has a Nuget Package referenced but is not referencing it in code anywhere how do I instruct Visual Studio to copy the files from that package to whatever folder I need them to go when I do a build?
Try to modify the package management to "Packages.config", it will auto copy the dlls to output folder.
If you want to copy dlls to other folder, you can use xcopy command in post-build event.
dotnet publish is the command you're looking for
dotnet publish compiles the application, reads through its dependencies specified in the project file, and publishes the resulting set of files to a directory. The output includes the following assets:
Intermediate Language (IL) code in an assembly with a dll extension.
A .deps.json file that includes all of the dependencies of the project.
A .runtimeconfig.json file that specifies the shared runtime that the application expects, as well as other configuration options for the runtime (for example, garbage collection type).
The application's dependencies, which are copied from the NuGet cache into the output folder.
https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-publish
I need to create a .NET Standard 2.1 NuGet package that contains a JavaScript file which will be added to my consuming application in the following path:
/wwwroot/js/myFileFromNugetPackage.js
(the consuming application happens to be a Blazor Server app)
I followed one example which used a *.targets file, but it didn't work for me.
The closest I got was to set up my NuGet project as follows:
Create a top level folder named "wwwroot"
Add the file "wwwroot/js/myFileFromNugetPackage.js"
In the properties for that JS file, set "Build Action = Content" and "Copy to Output Directory" = "Copy Always"
I publish this to my private NuGet library.
I then add that package to my Blazor (.Net Core 3.1) application.
When I look in Visual Studio's Solution Explorer, what I see looks promising:
/wwwroot/js/myFileFromNugetPackage.js
However...
If I manually create a new file in the same directory, so I now have:
/wwwroot/js/manuallyAddedFile.js
/wwwroot/js/myFileFromNugetPackage.js
When I go to the properties of the two files, I see different paths:
C:{some path}\MyApplication\wwwroot\js\manuallyAddedFile.js
and
C:\Users\{me}\.nuget\packages\{myNuGetPackage}\{version}\contentFiles\any\netstandard2.1\wwwroot\js\myFileFromNugetPackage.js
And unsurprisingly, when I attempt to use either of those JS file using Blazor's JS Interop, I can use the one I manually entered, but it can't find the one from my NuGet package. The F12 developer tools show only the manually created one present on the Client.
So, my question is: How do I set up my NuGet project to write a JS file so that it ends up in the correct directory?
And unsurprisingly, when I attempt to use either of those JS file
using Blazor's JS Interop, I can use the one I manually entered, but
it can't find the one from my NuGet package.
Because you can only in Blazor application (new SDK format) using packagesreference nuget management format, so you import package can only by reference links will be in the form of your files into the project in a package, so myFileFromNugetPackage. Js properties displayed in the path ../. Nuget/packages .
This is also a feature of the pacakgesreference nuget management format. By the way, this is not such case with packagesconfig nuget management format.
When you add a new item which means that you have created a file under your current solution, so you can find the new file under the solution.
I followed one example which used a *.targets file, but it didn't work
for me. So, my question is: How do I set up my NuGet project to write
a JS file so that it ends up in the correct directory?
Solution
To solve your problem you can add a target file to the nuget package which copys the actual file to the project so that it will be referenced in the main project and not referenced in the link.
I tried your link demo and it can successfully achieve your goal.
The core is this paragraph
<ItemGroup>
<SourceScriptFiles Include="$(MSBuildThisFileDirectory)..\content\scriptsToGenerate\*.js" />
</ItemGroup>
<Target Name="CopyScriptsToProject" BeforeTargets="Build">
<Copy SourceFiles="#(SourceScriptFiles)" DestinationFolder="$(ProjectDir)\wwwroot\js\scriptsToGenerate\"
/>
</Target>
Note:
In some cases, you might want to add custom build targets or properties in projects that consume your package, such as running a custom tool or process during build. You do this by placing files in the form <package_id>.targets or <package_id>.props (such as Contoso.Utility.UsefulStuff.targets) within the \build folder of the project.
This pre-processing target can only be executed at build time,
So I suspect you can't find the JS file in the main project without building the project. Hope it could help you.
Not sure if this is the correct place to ask this but there have been a lot of visual studio questions in the past here.
I am currently creating a lot of npm packages in a solution and as part of the package, I have to create a package.json file.
Once I save the file, it creates a node_modules folder and downloads all the dependent npm packages to it. Now I have got azure dev ops to ignore these files so they aren't checked in by adding the node modules folder to the list of ignored folder names, but I also want to exclude them from my project so that it doesn't lock my computer every time it tries to write all the file names in to the .proj file.
Is there a way to automatically tell the project or solution to auto exclude this folder - like a solution ignore file I can add the name to?
Or is there an option somewhere that folders that aren't created through vs, aren't automatically added to the project - this is how my earlier versions of vs worked - new folders not created through vs would have to be manually included if you wanted them in the project / solution
Ok this is due to the project type that I used when creating the project - I created it as a .net core project and that seems to add files by default and only exclude them if you tell it to, if I change this back to a .net standard project, it works as I would expect - only includes files you drag into the project or tell it to include
Is it possible to make a reference between two TypeScript projects? Assume we have the following project structure:
Module1.ts contains:
module TestModule {
export interface Interface1 {
}
}
Module2.ts contains:
module TestModule {
export interface Interface2 extends Interface1 {
}
}
Test1 is referenced in Test2. I get an error Could not find symbol 'Interface1' in Module2.ts. It works within one project, but I don't know how to make it visible from the other project... Maybe it's not possible for now.
[Edit 1.]
When I try to use TestModule.Interface1 pattern, I get the same error (said in different way). But the IntelliSense sees my Interface1:
[Edit 2.]
I have noticed I can't use files from the other project. Even if I have a correct reference (/// <reference ...) added and linked all the files in my 1st project.
There's lots of ways you can do this.
Option 1 - Project References (TypeScript 3.0+)
If you are using TypeScript 3.0 then look at using project references. Read more here.
Option 2 - Build script
Use something like gulp-typescript, grunt-ts, or just a batch script to copy the files over into a folder in the main project.
Alternatively, run a build event in Visual Studio that will copy the files over to the main project.
Option 3 - npm package
If you use npm, you could create a package for your other project. Then you can use your package in your main project. Specifying a local dependency is a good way to do this or by using something like sinopia, which is a private repository server. I've never used it, but it looks like it would work well.
Option 4 - NuGet package
You could look into creating a nuget package and then installing it locally.
Option 5 - --declaration --outDir compiler option
You can set the --outDir compiler option or the outDir property in tsconfig.json with the directory to your other project then also compile it with --declaration so that it generates the declaration files (.d.ts) too. For example: --declaration --outDir ../Test1/External.
Original Answer (Using --out)
You can do something similar in Visual Studio if you right click on your library project and click properties. In the TypeScript Build tab, check off the option to Combine JavaScript output into file and specify the location in your main project you want it to go (Ex. $(SolutionDir)/TypedApp/External/TypedLibrary.js). Then also check off Generate declaration files in order to generate a .d.ts file.
Once this is done, build your library project and then include the .js, and .d.ts in your main project. Include the .js file in your html and reference the .d.ts in your typescript files.
Each time you rebuild the library project, it will automatically update the main project with the changes.
The solution suggested by #dhsto works but I have found an alternative using linked folders. I have written about it in detail in this article, here is how it can be implemented:
It can be achieved by creating a folder to hold your references, I like to name this “_referencesTS”, the folder will contain all of the links to files from Test1. This can be done individually but would become very cumbersome if it had to be done for each new TS file. Linking a folder however will link all of the files beneath it, this can be done by editing the csproj file.
To edit the file right click the Test2 project and click “Unload Project”, then right click the project and click “Edit Test2.csproj”. Navigate to the <ItemGroup> that contains the <TypeScriptCompile> tags and insert the code below:
<TypeScriptCompile Include="..\Test1\**\*.ts">
<Link>_referencesTS\%(RecursiveDir)%(FileName)</Link>
</TypeScriptCompile>
Replace the relative path to the location of your TS files in Test1, this uses the wildcarding (*) to link all .ts files (dictated by the *.ts) within all sub folders (dictated by the \**\)..
The TS files within these folders will now appear linked within Test2, allowing for automatic typescript referencing.
Note: The only downside to this approach is that when a new file is added to Test1 within a linked folder, the user has to unload and load the project or close and open the solution for it to appear in Test2.
Frustrated with the state of affairs, I wrote a NuGet package that mostly solves this problem. Using the NuGet package you can just add a reference from one project to another and it will do the work of copying files around in a way that is safe from accidentally editing the wrong file and still gives intellisense and debugging.
Details can be found in the Readme.md, or you can just install the NuGet package and run (I recommend at least reading the how to use section).
https://github.com/Zoltu/BuildTools.TypeScript.FromReferences
I just want to add to the answer of David Sherret that the lib files to the TypedApp project could be added as Link files instead of depending on post build events. I'm having some issues with post build events in big solutions with a lot of projects, and the link files are now working ok for me. (I cannot add a comment to the answer because I only have 35 reputation points).
If you are compiling with the --out parameter you can simply reference Module1.ts from Module2.ts using /// <reference To learn more about code organization patterns in TypeScript see http://www.youtube.com/watch?v=KDrWLMUY0R0&hd=1
What visual studio language services sees available (which is everything) is different from what you compile and actually have available at runtime.
If you need to share the code between multiple projects you can always create a symbolic link on each project where you need it.
http://en.wikipedia.org/wiki/Symbolic_link
basarat's answer is the closest to being the most reliable solution for cross-project TypeScript references. However, when merging shared TypeScript code with a referencing project's TypeScript (important, for example, if you need to target different ECMAScript versions), the Source Map file doesn't resolve to the shared project's directories, so debugging won't work (in fact, Visual Studio often crashes after adding breakpoints to the files referenced in another project).
Linked files of any kind (Visual Studio links and symbolic links) don't work with debugging in any system (Visual Studio, Chrome, WebStorm, etc.)--linked files essentially don't exist to the ASP.NET debugger, nor any other debugger; they exist only in Visual Studio.
Please see this question/answer indicating what has worked great for both solid code maintenance and debugging in Visual Studio, Chrome, and Firefox, while still retaining the ability to combine shared code with the referencing projects' code (important, for example, if you need to target different ECMAScript versions): Visual Studio: How to debug TypeScript in a shared project using IIS Express and cross-project references (no linking or duplicating files)
The accepted answer disallows debugging in Visual Studio when a breakpoint is set in the Shared project. (At best the debugger will stop on a line in the compiled javascript, but not the original Typescript and certainly not in its original project location.)
In the Shared project's properties, let's say that Combine Javascript output into [a single] file is checked and set to AllShared.js, which also makes a AllShared.d.ts file because Generate declaration files is checked, and also makes a AllShared.js.map because Generate source maps is checked.
The referencing project should NOT copy or link these files in the way the accepted solution does. Instead:
Part 1, in the referencing project, create /typings/tsd.d.ts if it doesn't already exist, and append to the bottom of that file the line ///<reference path="../../SharedProject/AllShared.d.ts" />. Once this is done, (and at least one successful compile of SharedProject is done), Intellisense and the Typescript compiler should see Interface1 etc. (You'll likely get a red squiggly line underlining the statement if the path/file doesn't exist, which is nice.)
Part 2, in the referencing project's index.html, add the line <script src="http://localhost:29944/AllShared.js"></script> before that project's own script tags. The localhost part comes from the Shared project's Properties, Web tab, Project Url. (Both 'IIS Express' and 'Local IIS' work.)
Now when you run the referencing project, you should see Internet Explorer** request the relevant files from their respective "websites". Visual Studio breakpoints should be hit regardless whether they're in SharedProject or the referencing project.
. Although this solution works without gulp/grunt/powershell, Visual Studio's Combine Javascript output into one file doesn't glue together the files in any particular order, and it will eventually break your code. Then you'll need to add Gulp/etc. to the referencing project to insert a <script src="http://localhost:29944... tag for each file in Shared***, because keeping index.html updated by hand is a poor option. (Adding Gulp to the Shared project, to concat the .js and .d.ts files into singles runs into an issue with .js.map files, which can't be simply concatted.)
** IE and VS are both Microsoft products, so IE really works better if you want to use VS's breakpoints and debugger instead of a web browser's.
*** Gulp doesn't like injecting urls, only filepaths. Given HTML comments in index.html like <!-- SharedStuff:js --><!-- endinject -->, circumvent this like so:
gulp.task('insert-into-html', [], function () {
var common = gulp.src(['../SharedProject/**/*.js'], { read: false });
return gulp.src('./index.html')
.pipe(inject(common, {
relative: true,
name: "SharedStuff",
transform: function (filepath) {
return '<script src="http://localhost:29944/'+filepath+'"></script>';
}
}))
.pipe(gulp.dest('./'));
});
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.