I'm using TypeScript 0.9.5 and when I add a TypeScript file, I no longer see the compiled JavaScript file or the generated source maps in Visual Studio solution explorer.
Where have my JavaScript files gone?
Because the generated files are like binaries, they shouldn't really be part of your project or be added to source control.
In previous versions of TypeScript, having the files in the project / under source control could cause issues on build servers in cases where the build server was averse to changing files that are under source control.
Another problem caused by having the files in the project / under source control is that even if you don't change your TypeScript file, the generated files are re-created on build and are picked up by source control clients as being changes. These would all show as revisions if you checked them in (or you'd have to manually exclude the changes to avoid polluting your source control repository).
The new treatment of the generated files makes them more like your .NET DLLs - they get generated on the build server (and locally on your disk) but you don't need them in source-control.
click on show more in solution Explorer as shown in picture
click here to see image..
Related
I have developed an opencv application using windows form and C#.
The opencv packages I got from the Nuget packages manager (EMGU.CV and ZedGraph).
Everything works fine in visual studio, but when I publish the project and install the program in my machine, it throws an exception when I click a button that performs some opencv operations.
I guess the opencv packages didn't come along with the final published project, so how do I do to make it export when publishing, I thought it would be an automated process, I have already used other nuget packages and I had no problem with it.
What Am I missing here?
After some days waiting for an answer, and looking for solutions, I've figured it out how to solve this issue.
I came across this question:The type initializer for 'Emgu.CV.CvInvoke' threw an exception
Which led me to this: http://www.emgu.com/wiki/index.php/Download_And_Installation#The_type_initializer_for_.27Emgu.CV.CvInvoke.27_threw_an_exception.
More precisely this part:
First of all, I don't know why the compilation runs fine inside visual studio enviroment and why not when publishing the project as it is. For some reason, the Nuget packges are not enough for publishing the project, you need to add the .dll files manually yourself (not sure why this occurs once I have worked with Nuget packages before and this workaround was not necessary).
To find the .dll files you go to your project directory, then you go to bin\Debug\x64 or bin\Debug\x86 (depends on which operating system you are targetting - 32 bits or 64 bits -in my case I added all .dll files from x86 folder, I guess you can add from both folders if in doubt).
The Debug folder of your project is build every time you run the project inside Visual Studio enviroment, so if your Debug folder is empty then you just need to run the project one time to be able to find the auto generated files inside that folder. Just a side note here, you can use either the Debug or the Release folder inside bin, just remember to check if you compiled the project in Debug mode for Debug folder, or Release mode for Release folder, otherwise the desired folder will be empty, as explained before, I found no differences between the files generated, I added the dll files from Debug\x86.
Once you have located the .dll files, you go to Visual Studio, right click on the project in the Solution Explorer tab, then Add ---> Existing Item.
Go to the folder where the .dll files are, select all and click Add.
Once you have done this, the .dll file will be shown in the Solution Explorer.
Right click on each .dll file added in the Solution Explorer, and open the properties tab by clicking Properties. On the Properties tab, go to option Copy to Directory and change the field to Copy Always (the emgu documentation link provided above states to use the option "Copy if newer", but to make sure I chose "Copy always", it worked fine for me). Repeat the process for all .dll files added.
Now you are ready to go for publishing the project as it is,just remember doing this every time before publishing your project to see if no .dll files are missing, so once you got to final version of your program, run it, and then make sure to check the .dll files, it might have new ones to add or to remove.
I'm using Visual Studio 2015 update 3 with TFS hosted at visualstudio.com.
When I add a C# class file to one of my projects in Visual Studio, it's not automatically added to source control. For other projects in the same solution, C# class files are added automatically, as expected.
When I then add the file, manually, in the project with this problem, I get the following question;
I have to confirm to add the file to source control.
There is a similar question (Visual Studio 2015 new files not being added to source control automatically), associated with a "release" branch, which is not the case here (at least I think so - our TFS-project has never been branched)
We've never configured any .tfignore manually.
This started to happen recently and occurs on all development machines, so it's probably not a client machine issue.
I'm clueless, so any help is highly appreciated.
UPDATE
I've discovered that the problem occurs in projects with names ending with ".Lib"
Projects:
Core (ok)
Core.Lib (files not added automatically)
Communication (Ok)
Communication.Lib (files not added automatically)
I tried to add a test project Test.Lib to my solution. This project was not added to TFS either, but project Test was.
The "lib" extension is the problem. Try renaming the project folder to something else, eg. "CoreLib".
To reproduce this behavior / bug, try the following:
Create a Test directory in a directory controlled by TFS
Create a Test.Lib subdirectory in this directory.
Add a file, test.cs, to Test.Lib. (Test\Test.Lib\test.cs)
In Visual Studio's Source Control Explorer, try adding the new Test directory to source control. You'll see test.cs on the "Excluded items" tab.
The "lib" extension is used by binary files, and these are ignored by Team Explorer by default. I haven't found an official list of filetypes anywhere, but other affected file types are dll, exe, obj and possibly others. You can include these files manually by right-clicking them and selecting "Include".
I've got ~30 SpecFlow feature files, and I recently removed the Foo.feature.cs files from source control because I got sick of resolving merge conflicts in Designer Generated code.
I did not exclude or remove these files from my Visual Studio project, so Visual Studio still thinks they should be there, they are just missing on the hard disk.
Ideally I'd like to just click on a root folder and regenerate all the code behind files, but no such option exists for VS 2010 and SpecFlow 1.9. I'd even be OK with programmatically regenerating them from the command line, creating another custom tool or adding a pre-compile build event.
Is there a way to regenerate all of the the Designer generated code behind files for SpecFlow features (*.feature.cs files) without right-clicking on each .feature file and clicking "Run Custom Tool"?
You can right click on the project and choose 'regenerate feature files' to do them all at once.
It runs much quicker from the command prompt. Go to your Specflow package tools folder and run the following command line. It also ensures the correct Specflow version is added to the files.
specflow.exe generateall <My_Testing.csproj>
My project files are controlled by Perforce and I have installed the SCC plugin so that I can work directly with Perforce inside Visual Studio 2010.
Here is the problem I have:
Inside the project, there are several files that I don't want to take into consideration while I build the project. If I use the context menu "Exclude from Project", I saw the following warning message:
Checked out items cannot be deleted by your source control provider.
If you continue with the change, you may need to manually delete
xxx.h in the source control database.
Is there a workaround that I can use?
Thank you
If you simply do not want them to compile, select the code file and look at the Properties window. Set Build Action to content or some other non-compile setting.
Here's my specific scenario: Using VS2010, Pex and TFS2008, generated moles files are getting automatically added to source-control (TFS).
Pex adds a "project_name.moles" file to your test project and then autogenerates 3 files at build time: project_name.Designer.cs, project_name.Moles.dll, and project_name.Moles.xml. I want to keep the *.moles files in TFS (it's source code) but I don't want the 3 generated files to be in TFS (they are still part of the project, but they are generated when first built on a new system).
There are two reasons I need this behavior:
1. It's not a good idea to store generated code in source-control (let's not debate the merits of that here).
2. Specially, the DLL file is BAD because every time someone builds, all moles files are regenerated and thus all files are checked-out and DLL files are checked-out EXCLUSIVELY (non-mergable) and so other people can no longer build on their local box.
The Pex/Moles team are working on this but the solution is still likely several months away.
Is there a csproj property that can be assigned to these project files so that they are in the project but not managed by version control? I don't mind hand-editing the csproj file.
Moles will not be adding any files to the project in the next version (v0.94). It will use MSBuild to generate the assemblies on demand.
I think it depends more on the version control tool than Visual Studio, as usually you can set up some kind of filters in your version control configuration in order to exclude some files/paths.
E.g. if you use Mercurial/Hg, you can (and should) edit your repository .hgignore file and specify e.g. to exclude all *.moles files and the whole sub-tree MolesAssemblies\*. I guess other version control systems have similar options.