I am writing a website in VS2015 using the ASP.NET Preview template. Unfortunately, Dropbox has added a bunch of .dropbox.attr files in each folder of my project, which the Solution Explorer is displaying:
Note that I have not added them to the project manually, (they are not referenced in my Web.xproj,) and I do not have "Show All Files" selected. I have already added them to my .gitignore. There is no "Remove" option when selecting the file:
Lastly, I have tried adding them to my project.json's exclude section:
...
"publishExclude": [
"node_modules",
"bower_components",
"**.xproj",
"**.user",
"**.vspscc",
".dropbox.attr"
],
"exclude": [
"wwwroot",
"node_modules",
"bower_components",
".dropbox.attr"
]
...
Is there any way to get all files with this name to not appear in my Solution Explorer?
I'm not sure exactly of the interaction between VS2015 and the new project structure, so it could be a result of any of those factors.
You can modify the .xproj file of your project and add the following to exclude folders:
<ItemGroup>
<DnxInvisibleFolder Include="wwwroot\jspm_packages\" />
<DnxInvisibleFolder Include="wwwroot\node_modules\" />
<DnxInvisibleContent Include="wwwroot\tsd.json" />
</ItemGroup>
You can use DnxInvisibleFolder for folders and DnxInvisibleContent for files.
Some folders (like node_modules) have sometimes thousands of folders/files which seem to pose a major problem for VS2015 to scan and load.
In a DNX project in visual Studio 2015 the solution explorer does not use the project.json to determine what is shown. The "exclude" properties in project.json are used by dnx to determine which folders/files should be excluded from compilation or publishing but this does not affect Visual Studio's solution explorer.
Generally speaking "everything" is shown but that isn't exactly true as VS excludes certain folders (such as .git, .vs, artifacts, etc). It also adds back others (i.e. bower components is excluded by default from compilation but VS adds it back as a meta folder under dependencies). The "filter" for Solution Explorer is not exposed to the user so it can't be edited or changed by configuration file.
Your best bet would be to request via user voice that some method of configuration be added. Really the functionality is already there it just needs to be made customizable by the user.
With the latest Visual Studio you just need to right-click the folder/file and chose "Hide from Solution Explorer".
That will change the "xproj" this way like Corneliu wrote before:
<ItemGroup>
<DnxInvisibleFolder Include="wwwroot\" />
</ItemGroup>
Related
Can't find an simple, basic solution anywhere for this problem so I figured it was worth posting it here.
When I go to run my code as a task, I get the following message: "Tasks are only available on a workspace folder" - I can't find a solution anywhere and I'm a beginner at Visual Studio Code so I might need the answer / solution explaining in more simpler terms.
VSC Version = 1.17.0
Visual Studio Code treats the folder containing your program file as a workspace folder.
Your tasks created will be contained in a file tasks.json within a hidden folder .vscode inside your project or workspace folder.
So instead of opening the file directly to create a task, you need to open the folder as a project.
The "Workspace launch configuration" section of VSCode mentions:
With multi-root workspaces, VS Code searches across all folders for launch.json debug configuration files and displays them with the folder name as a suffix.
Additionally VS Code will also display launch configurations defined in the workspace configuration file.
Example of settings: vscode-tslint/vscode-tslint.code-workspace
As an alternative, you can have User level tasks to share them across projects since VSCode 1.42 (Jan. 2020).
But regarding workspace tasks, since VSCode 1.57 (May 2021), said tasks will have to be "trusted" by anyone opening the same workspace, assuming you have versioned and pushed the .vscode folder.
Safe code browsing
It's great that there is so much source code available on public repositories and file shares. No matter the coding task or problem, there is probably already a good solution available somewhere.
However, using open-source code and tools does have risks and you can leave yourself open to malicious code execution and exploits.
Workspace Trust provides an extra layer of security when working with unfamiliar code by preventing automatic code execution when a workspace is open in Restricted Mode.
Is it possible to switch back to packages.config scheme of things? I moved to PackageReference scheme when I created the project, but for some reasons need to move to old way of things now.
I have tried Package Manager Console commands like restore with Update and Reinstall options. They do not generate packages.config anymore. I also switched Tools > Options > NuGet Package Manager to packages.config. No good.
You'll need to:
Add an "empty" packages.config file to the project (that is, xml as in the example but without individual <package> elements)
Unload the project or close vs and open the csproj file in a text editor.
Remove all PackageReference elements out of the project file.
Make sure that <RestoreProjectStyle> is not set in the project file.
Reopen the project in VS.
There was one step missing for me:
4.5. Make sure that Tools>Options>NuGet Package Manager>General>Default package management format is set to Packages.config
Wanted to add one more thing. I tried all above steps and Visual Studio kept trying to use the global-packages location, instead of repositoryPath from Nuget.config. Finally found that there was a package-lock.json file in the obj dir of my projects that had the global package dir stored in it. For some reason the Clean operation, in Visual Studio, didn't delete the file, so I wound up doing a
git clean -x -d -f
At the root of my repository. Which deletes all un-tracked files and directores, and ignores the patterns the .gitignore file. It was a bit excessive, I could have tried to find them all by hand, but it got the job done. Now Nuget restore properly uses the repositoryPath setting specified in the Nuget.Config file.
How I made it work:
Take of screenshot of the packages we use in this project
Add an "empty" packages.config file to the project and copy this into it:
<?xml version="1.0" encoding="utf-8"?>
<packages>
</packages>
Unload the project and open the csproj file in a text editor.
Remove all PackageReference elements out of the project file.
Make sure that <RestoreProjectStyle> is not set in the project file.
Make sure that:
Tools >
Options>
NuGet Package Manager >
General>
Default package management format is set to Packages.config
Delete the obj folder in the project
Use the screenshot to re-download the packages again
Hi,
Shared project seemed like a good idea to share code between .NET Core 2.0 web project and .NET 4.7 WinForms project.
I have bunch of extensions inside as well as web api client code which is used by both projects.
Everything works well in Visual Studio 2017.
However, on the road I use MacBook computer with Visual Studio Code which does not recognise shproj in any way. I also tried Insider version with new multiple workspace, but that also seem to work only with actual projects (csproj).
I know there is Visual Studio for Mac, but it is huge and far exceeds my on-the-road needs, so I would like to avoid it.
So, my question is - is there a way to utilize Visual Studio Code with projects that use shared projects (shproj)?
I would like to run/debug such projects in VSCode.
If not, does it make sense to create feature request somewhere? I mean, shared projects were designed for cross-platform code sharing and VSCode is brilliant cross-platform editor so it makes sense.
Or is this not part of VSCode at all, but some extension (like OmniSharp)?
Thanks,
Mario
At least now (2021) it seems to work fine.
TLDR; Create a new project with Visual Studio (2019) and add a "Shared Project" to that Project/Solution. Then open the project folder in Visual Studio Code and add the Shared Project folder to Workspace. In VS Code add a new Class to the Shared Project and adjust the *.projitems file to include the new class in the compile process. Run the project in both VS Code and VS to verify everything works as expected.
Following are the steps that I used. It looks like a lot, but it should only take about 10 minutes to setup this basic sample.
Open Visual Studio (2019)
Create a new "Console App (.NET Core)", give it a name and a location and select "Place solution and project in the same directory".
After creating the project you should have a new solution in "Solution Explorer" containing the new Console Application project.
Right-Click on the solution and select "Add" > "New Project..."
Select and add a new "Shared Project"
Add a new class to your Shared Project. In "Solution Explorer" right-click the shared project and select "Add" > "New Item..." and select the "Class" template.
In your "Console Application" add a reference to your Shared Project by right-clicking on your Console Application project, then select "Add" > "Shared Project Reference..." and select the listed shared project (*.shproj)
Use the new class of the Shared Project in the Console Application project
Run the Console Application to check if it builds and uses the shared class successfully.
Close Visual Studio (2019)
Open Visual Studio Code
Select "File" > "Open Folder" and select the folder where the Console Application is placed.
Note: If VS Code shows a message "Required assets to build and ... are missing" then select "Yes".
Select "File" > "Add Folder to Workspace..." and select the folder where the Shared Project is located.
Select "File" > "Save Workspace As..." and save the file to the project folder of the Console Application.
Open a new integrated Terminal in VS Code (in Menu "Terminal" > "New Terminal") and make sure that the current working directory is the folder of the Console Application. Then type "dotnet clean && dotnet run" to clean, build and run the solution.
Assuming we now want to add a new Class to the Shared Project from Visual Studio Code, we have to do some extra work, that normally Visual Studio (2019) would do for us when adding a new Class.
In VS Code right-click the folder where your shared class is located and add a new File. Give it a name with .cs extension and add the according code to the file to make it a valid class file.
Open the *.projitems file and find the part where your first class file has been added already. It should look like this:
<ItemGroup>
<Compile Include="$(MSBuildThisFileDirectory)SharedClass1.cs" />
</ItemGroup>
Now add the new class file to this ItemGroup section like this
<ItemGroup>
<Compile Include="$(MSBuildThisFileDirectory)SharedClass1.cs" />
<Compile Include="$(MSBuildThisFileDirectory)SharedClass2.cs" />
</ItemGroup>
Use the new class in the Console Application, save all files and type "dotnet run" in the integrated Terminal.
Check if everything builds and runs as expected.
If you notice that it builds successfully, but VS Code shows some error like "The type or namespace name 'Class2' does not exist in the namespace 'SharedProject1'", then restart VS Code. After restart it should be able to detect everything as expected.
Close VS Code and Open VS (2019) by double-clicking the *.sln file.
Build and Run the project to verify that all changes are compatible with VS (2019).
I come from IDEs which support the concept of "project", that is an entity which encompasses specific files (and folders) and associated configuration and are visually independent form each other. They can also usually be opened as "projects", bringing in everything which is associated to them.
The closest I could find in VS Code are workspaces, which seem to be folders with a .vscode subfolder which may contain a configuration file specific to that subfolder. They are not specifically visible within VS Code (with the ability to open them for instance)
Is this indeed how projects are managed in VS Code?
The documentation mentions that a "project" can also be opened:
Open a project
vscode://file/FULL/PATH/TO/PROJECT/
but it may just be a name for "folder with a .vscode subfolder within"
There is an extention project-manager.
With this you can save project or open list of saved projects shift+alt+p. It also says (I never used this feature) that you can turn on auto-detection of projects (vscode or git or svn).
I have 2 TFS projects on the same server (ProjectA and ProjectB). Both have the following structure...
$/ProjectName/Dev/Source/ApplicationName/
$/ProjectName/Dev/Source/SharedBinaries/
In ProjectA I can drag dlls into the ShareBinaries directory. In ProjectB, however, I cannot. TFS presents me with the 'Add to Source Control' dialog in which all the dlls are in the 'Excluded items' tab. Each dll has the description 'The item cannot be added because its destination path is cloaked.'.
I can see no difference between how the 2 projects are setup. Help, I'm stumped!
Take a look at your workspace mappings. It sounds like when you drag & dropped the files, Visual Studio created an extra workspace mapping.
I edited the Workspace and added a specific mapping for:
$/ProjectB/Dev/Source/SharedBinaries/*
I also then renamed the existing windows folder, added the SharedBinaries folder through TFS, checked it in then, finally, I was able to drag and drop the dlls. Not quite sure which bit of all that was the key though!