I am using typescript 1.5 and VS 2015 RC with new ASP.NET 5 Project templates.
Typescript compiles fine however I am getting the following error on my exported classes:
cannot compile external modules unless the "-module" flag is provided
I want to silence this error however I am unable to specify any typescript options though VS 2015. I also tried tsconfig.json file however it seems it is not effective to just add this file. Perhaps there is an additional step I am missing. What can I do ?
Typically this setting is in the project properties on the TypeScript build tab in the project properties (for your current build configuration such as Debug or Release).
Since you are saying that the TypeScript build tab doesn't appear, you may not have a valid reference to the TypeScript "props" file in your project. Look for a line like this in your .csproj or similar file:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props')" />
If it doesn't exist, add it to your project and then fix up the path to be correct for your install of Visual Studio and TypeScript (just search for the "Microsoft.TypeScript.Default.props" file on your hard drive). When you reload the project, the TypeScript build properties tab should appear.
The other thing you need is a reference to the TypeScript "targets" file such as this:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets')" />
Note that a targets reference generally has to be as low as possible in your project - possibly even just before the </Project> tag.
Initialization of TypeScript in Visual Studio is dependent on the .props and .targets files existing so that could also be the issue.
Related
In Visual Studio 2019, is there any easy tool to update source map file (css.map) from a css and min.css files?
I have a default.less file in a project which contains a default.css and then nested to it two files: default.css.map and default.min.css
+ default.less
|
|-----+ default.css
|
|-----+ default.css.map
|
|-----+ default.min.css
I have never worked with less. This project was build by other people. It seems there is installed a nuget package called dotless in the project. I am completely new in this project assigned, I have to maintain it.
When asp.net mvc app is executed I get an error which says it cannot parse content for default.css.map file. It seems default.css.map file is not correctly updated from default.css and default.min.css.
So now I am trying to update default.css.map file from default.css and default.min.css. I have no idea on how to do it. Any ideas?
I have always found using explicit .map files annoying. Near all LESS compilers come with an option to compile the map source into the .css file. This is the best option as it is always up to date and then you can just make a prod config that does not include the map.
I mostly use WebCompiler in my mvc apps, although webpack also has this functionality.
I tried using Dotpeek and ILSpy.Net to decompile (my own code), they failed.
Do I need special obfuscation on distributed binaries of .Net Core 3 self-contained single executable ?
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.0</TargetFramework>
<PublishTrimmed>true</PublishTrimmed>
<PublishReadyToRun>true</PublishReadyToRun>
<PublishSingleFile>true</PublishSingleFile>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
</PropertyGroup>
</Project>
The single-file exe is really an unmanaged wrapper and ILSpy doesn't support decompiling this. But when you run the exe, it unwraps its contents to a temp folder. So you can find the managed dll there and decompile it using ILSpy.
To find the temp folder, you can use any tool that shows locations of assemblies loaded by a process. SysInternals Process Monitor (procmon) is a good one.
You can setup procmon to filter by your exe name, and when you launch your exe, procmon should show some events for assemblies being loaded from a temp folder:
You can browse to that folder and find your managed dll there. And you can decompile using ILSpy from that location.
I wrote a blog entry: https://eersonmez.blogspot.com/2020/02/ilspy-decompiling-net-core-self.html
I wrote a small dotnet tool after I stumbled upon this question and couldn't find a lightweight tool myself other than ILSpy.
You can install it using the following dotnet command: dotnet tool install -g sfextract.
After installing it, run it using the following command: sfextract application.exe -o output-dir
The bundle format for .NET 5.0 (bundle version 2) is identical to previous versions. .NET 6.0 (bundle version 6) has an additional field for each file entry containing the compressed size, since single-file applications can now be compressed using gzip by setting EnableCompressionInSingleFile to true.
https://www.nuget.org/packages/sfextract/
https://github.com/Droppers/SingleFileExtractor
Update 07/2022: .Net 5 single-file does not automatically unpack to the same temporary location as before. to force it to be unpacked you would need to add the following:
in the project file add these properties (according to theseMicrosoft docs):
<PublishSingleFile>true</PublishSingleFile>
<IncludeAllContentForSelfExtract>true</IncludeAllContentForSelfExtract>
Add an environment variable DOTNET_BUNDLE_EXTRACT_BASE_DIR with the location you want the files extracted to.
Update: One of the announcements made regarding .Net 5 states that the way single-file executables will be made would change, so this method will not work for them.
I wanted to add on #Eren Ersönmez's answer, that while ILSpy DotPeek don't support this at the time, since the self-contained single file is just a wrapper that contains all your DLLs and gets extracted on runtime, simply knowing where it is extracted to can save you using ProcMon or ProExp or windbg.
If you use windows you can go to c:\Users\{Local Username}\AppData\local\temp\.net\{Name of executable}
which should lead to somewhere similar to
c:\Users\alenros\AppData\Local\Temp.net\MyTestApplication
Launch your exe, and a folder with the same name will be created in that location.
The folder will contain randomly named folders. open the latest one and there you will find all your extracted DLLs, which can then be decompiled.
I have a project on Visual Studio 2010, which uses integration with Qt 4.8, some of boost features and all this stuff is versioned with SVN.
Everything was fine: I moved solution folder from one place to another, compiled it on different computers.
But once I've renamed solution folder, and when I tried to build the project - compiler wrote only one error:
Error 1 error MSB6006: "cmd.exe" exited with code 1. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets 151
But when I return old solution folder's name - everything builds without any errors again!
As i figured, compiler cannot use custom build steps for *.ui files and stops whole build process.
Probably, there is some issue with absolute pathing, but I cannot find it second day :(
As it often happens, the answer was hiding right on the ground.
While observing build output I got lines like this:
1> Uic'ing frmserver.ui...
1> File 'C:\Users\Theurgist\Desktop\JamServer (?????)\JamServer\frmserver.ui' is not valid
This issue was all because Qt compiler tools can't work with unicode-containing paths correctly (at least up to version 4.8)
There must be some references to the old folder location in either your .sln file or your .vcxproj file(s).
You should be able to fix this by:
Closing Visual Studio
Opening your .sln file and all the .vcproj files it loads in a text editor of your choice
Doing a search-and-replace for the old folder name, changing it to the new folder name.
Im trying to learn to make a web installer using Windows Installer XML (WIX 3.5). I found this blog about using msbuild in .wixproj files to avoid the scenario where the installer ends up dropping the web project assemblies right in the root of the app instead of keeping them in the bin folder like they're supposed to be.
Here is the link to that:
<http://www.paraesthesia.com/archive/2010/07/30/how-to-consume-msdeploy-staged-web-site-output-in-a.aspx>
But after adding the MSBuild scripts in the .wixproj file, I don't know what to do anymore. According to the instruction after adding the MSBuild script:
"When that target runs, you'll see a .wxs file pop out in the .wixproj project folder. Add the generated .wxs to your .wixproj project so it knows to include it in the build."
I really don7t know what this means. How can I run the target? I tried to build it but there was no .wxs file generated in the .wixproj folder.
Am I missing something? Please help...
Assuming you have added the section from the tutorial:
<Target Name="BeforeBuild">
...
</Target>
The target will be run automatically when you build the project. The "BeforeBuild" target is one of the standard entry-points to add your own modifications to the build. The target will then generate a file (named [WebProjectName].wxs that is placed in the same directory as your wixproj file. Click on the show all files button in visual studio and right-click on the file and "Include in project" That will then include the wxs is your installer and when you next build it will have the correct folder/file structure.
I'm using msbuild to automatically build and package a website ready for deployment. When I compile and then Publish my project through Visual Studio 2008 everything works fine.
However when I use msbuild I'm getting errors because AspNetCompiler is trying to compile aspx and ascx files that are not included in my .csproj, but still exist in version control.
I know I can just remove them from version control, but can anyone tell me why these files are being compiled?
Here is my msbuild task.
<AspNetCompiler
TargetPath="$(PackageDir)\Web"
VirtualPath="/"
PhysicalPath="$(buildDirectory)\Web"
Force="true"
/>
Thanks!
The AspNetCompiler task, which wraps _aspnet_compiler.exe_, compiles all "compilable" files in the application, rather than compiling only those files in the .csproj.
The giveaway is that none of the command-line parameters for the executable take a .csproj as input, only paths. (I suppose one could argue that it would look for a .csproj in the directory, but that is unlikely as it would introduce its own set of issues, such as what to do if someone had put two project files in one directory.)