Goal - I am trying to change the visual studio solution explorer collapse settings, so that files with extensions such as .razor.css are collapsed under their 'parent' file so to speak.
Expected - My laptop environment does this automatically, I simply name the file (i.e. Index.razor Index.razor.css) and the situation resolves itself without any input from me.
Actual - My desktop environment does not do this, for some reason it lists all the files consecutively, only collapsing from the folders.
I have, no doubt, unchecked a box somewhere to get myself into this mess. I would rather not attempt to fix the problem with explicit entries in my .csproj or registry as recommended in this SO question, unless I absolutely must.
If anyone knows a way to control or edit this behaviour in Visual Studio Community 2022 then please do let me know!
The feature you're looking for is called File Nesting. It is customizable, but in web projects should also have smarter defaults for most of the file types shown.
For non-web projects, you may need to enable it manually. See this GitHub issue for details, but the TL;DR is to add this to your project file:
<ItemGroup>
<ProjectCapability Include="ConfigurableFileNesting" />
<ProjectCapability Include="ConfigurableFileNestingFeatureEnabled" />
</ItemGroup>
If you're in a web project or have applied the workaround, I'd first check that the feature hasn't been accidentally disabled. If it's enabled and still not working, consider filing a bug via the VS Feedback tool or via the GitHub repo mentioned above so the feature team can follow up with you directly.
Related
Although I came across this question but the link in accepted answer seems dead, and also this question is about VS 2008.
I am using VS2015, (and VB) and I have the same scenario. The configuration dropdown is still disabled. How do I set different application icon for different configurations?
Thanks
You can use pre-build step, or you can manually edit the project file in notepad to achieve the goal as mentioned here and also here.
So I recently updated Visual Studio 2012 to Update 2. Lo and behold, the next time I go to publish my application (via File Publish in this case) I notice that there are three new options:
Delete all existing files prior to publish
Precompile during publishing (with a link to Configure)
Exclude files from the App_Data folder
The first and third options are pretty self-explanatory, but I can't find any documentation on the second option as it applies to MVC. When I check it, there doesn't seem to be any change in the files produced on the site and I don't see any real change in performance.
Using the ASP.NET precompiler can have the following impact on your MVC app:
If you have anything in App_Code, it will be precompiled into a DLL before deployment. Without precompiling, this would happen on the fly by the ASP.NET runtime.
If you choose the option to not make your pages updateable (i.e. uncheck the first checkbox in the advanced settings dialog), it will also precompile your views (ASPX and Razor) instead of compiling those dynamically at runtime as well. The default (checked) setting of "Allow precompiled site to be updateable" allows you to update your view content without needing to rebuild the entire project.
If you don't have any files in App_Code and you want your site to remain updateable, it doesn't seem to do much.
It is an old question, but I just encounter similar issue and feel something worth sharing.
My error message is same in this post. My project is MVC5, build with Visual Studio 2013 professional.
Compilation Error: The type 'ASP.global_asax' exists in both DLLs
In my case, with precompile option, there is a file, App_global.asax.dll, in bin folder, and cause above error message.
First, I remove App_global.asax.dll on server, restart application pool, issue is gone.
Then I tried another approach, uncheck precompile and republish, redeploy to server, issue is gone.
For Noda Time version 1.1, the main goal is to build a Portable Class Library flavour, primarily to support Windows Phone and Windows Store apps. This means losing some functionality, so we build a desktop configuration and a PCL configuration (for each of debug, release, and "signed release").
To avoid having to work with umpteen project files, all of the 6 configurations exist in the same project file. The project file is customized to generate a property called "Portability", which is set to either "PCL" or "Desktop", like this:
<!-- Set the custom Portability property based on configuration -->
<PropertyGroup>
<Portability Condition="'$(Configuration)' == 'Debug Portable'">PCL</Portability>
<Portability Condition="'$(Configuration)' == 'Release Portable'">PCL</Portability>
<Portability Condition="'$(Configuration)' == 'Signed Release Portable'">PCL</Portability>
<!-- Default to desktop if not explicitly set above -->
<Portability Condition="'$(Portability)' == ''">Desktop</Portability>
</PropertyGroup>
We then have separate property groups for portable vs desktop, based on the above property. This is what defines the project type as "class library" or "portable class library" (along with the OutputType of Library, which is shared):
<!-- Desktop-specific properties -->
<PropertyGroup Condition="'$(Portability)' == 'Desktop'">
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
<TargetFrameworkProfile>Client</TargetFrameworkProfile>
</PropertyGroup>
<!-- PCL-specific properties -->
<PropertyGroup Condition="'$(Portability)' == 'PCL'">
<MinimumVisualStudioVersion>10.0</MinimumVisualStudioVersion>
<ProjectGuid>{c78f6992-28d7-45c9-a4c1-6eaa649f3247}</ProjectGuid>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<TargetFrameworkProfile>Profile2</TargetFrameworkProfile>
<ProjectTypeGuids>{786C830F-07A1-408B-BD7F-6EE04809D6DB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
</PropertyGroup>
This generally works very well - I have the different solution configurations, so I can build and test everything at a moment's notice, and I only need to add each new .cs file to a single project file. So under Visual Studio 2012 Professional (which is what I use) I'm perfectly happy.
The problem comes when I try to load the solution in Visual Studio Express (either VS2010 or VS2012). While the solution is loading, it fails with an error to say that some projects can't be loaded, and the two projects which build PCL versions then have build output like this:
C:\Path\To\NodaTime.csproj : error :
The project file 'C:\Path\To\NodaTime.csproj' cannot be opened.
There is a missing project subtype.
Subtype: '{786C830F-07A1-408B-BD7F-6EE04809D6DB}'
is unsupported by this installation.
(Reformatted for clarity.) The two projects refuse to load, so you can't even browse the source code.
I had really hoped that even if Express users couldn't build the PCL versions, they'd still be able to load up the solution, browse the source, and build non-PCL versions. MSBuild works from the command line, but that's not as friendly.
I've tried removing the solution configurations which refer to the PCL project configurations, and that doesn't help. Weirdly enough, even commenting out the XML element, like this:
<!--
<ProjectTypeGuids>(Guids as before)</ProjectTypeGuids>
-->
doesn't help - although deleting the line does. It's as if Visual Studio isn't actually loading it as a real XML file. (I haven't tried loading the version with the commented out element into VS Pro.)
I could go down the route of generating separate PCL project files if I need to, but I'd really like to avoid it if possible - it would make normal development more painful. Likewise I could generate Express-only PCL and solution files, but again I'd rather not - it just feels wrong.
While ideally I'd like to support VS Express both 2010 and 2012, if there's a solution which only works for 2012, that would be a good start.
So, is there any way of persuading Visual Studio Express that it really can load a project despite a conditional property group (whose condition isn't met) referring to a project type it doesn't know about?
David Kean's comment here gave me the answer I'm using for the moment:
or remove the <ProjectTypeGuid> element entirely - this will opt you of "portable" enhancements, such as a UI for changing the target framework, etc
I've tried that, and it works like a dream. On machines which have everything appropriately installed, you can then even build the PCL version under Express! I've verified that the resulting binary really is a PCL, and it seems fine.
I wouldn't be surprised to find that I ran into some problems later on, but for the moment this works fine for me. I can easily live without the enhancements in Visual Studio - it was already confused by my project having very different build configurations, so I don't think I was getting much benefit anyway.
As answered here:
Visual Studio 2012 Express with Portable Class Library?
and here:
Share functionality using Portable Class Libraries
Portable Class library projects are not supported in the express
SKU...need a higher SKU for the full support. Of course the binary
(e.g., using it as a reference) is, just not the project/source
support.
I can imagine there is a simple reason for that - there are different types of VS2012 Express editions: for Windows Phone development, for Desktop apps, for Windows 8 apps... I bet the Windows Phone Express edition does not know about the Windows Phone project type and vice versa. This could be the simple reason why PCLs are not supported as well.
Although the idea of Portable Class Libraries is really nice, it's still quite limited in many ways, for instance you cannot use conditional compilation using #if xy as far as I know. If you really have to use Visual Studio Express for development, then it might be better to use projects for each platform with referenced source files and conditional compilation.
We current do manual builds/publish from Visual Studio 2010 and we require users to always be running the latest version (check before startup and minimum required version set). I am working on scripting our deployment out and have no issues using msbuild to build/publish. However, I have not found a way to auto-increment the minimum required version when msbuild runs. What are my options to automatically bump this when publishing via msbuild?
I did see quite a few articles on this topic here, but they seemed to be specific to VS and not MSBuild.
Updating the MinimumRequiredVersion Automatically
Introduction to Project Editor
In Solution Explorer, right click on your project and select unload project.
Once the project has become unavailable, right click again and select edit <project_name>.<lang> proj.
Introduction to MSBuild
Properties use key/value pairs to extract information
Using the property name as an alias, you can use $(OutputPath) to obtain the value for the element <OutputPath>.\bin</OutputPath>
We’ll use the following properties generated for a ClickOnce deployment
<MinimumRequiredVersion>1.0.0.6</MinimumRequiredVersion>
<ApplicationRevision>7</ApplicationRevision>
<ApplicationVersion>1.0.0.%2a</ApplicationVersion>
MSBuild Tasks can be specified in the project (*.proj) file and invoked during a build event.
FormatVersion is a built-in task for .NET 4.0 and later that formats the ApplicationVersion and ApplicationRevision into a single version number.
Implementation
Copy and Paste the following code into the opened project file as a child element to the root <Project> element.
<Target Name="AutoSetMinimumRequiredVersion" BeforeTargets="GenerateDeploymentManifest">
<FormatVersion Version="$(ApplicationVersion)" Revision="$(ApplicationRevision)">
<Output PropertyName="MinimumRequiredVersion" TaskParameter="OutputVersion" />
</FormatVersion>
<FormatVersion Version="$(ApplicationVersion)" Revision="$(ApplicationRevision)">
<Output PropertyName="_DeploymentBuiltMinimumRequiredVersion" TaskParameter="OutputVersion" />
</FormatVersion>
</Target>
This code will take ApplicationVersion and ApplicationRevision as parameters in the Format Version task and will save the output by overwriting the MinimumRequiredVersion with the full publish version.
Save and reload your project. Every ClickOnce deployment will now automatically update to the most recently published version.
Many thanks to Kev for their answer which I have basically rehashed here with a little bit of added clarification for any beginners. Here's a blog post I made about the issue that expands even more on my answer here.
Right now, I'm leaning towards updating the MinimumRequiredVersion via a custom command-line utility that will simply read in the project file and increment it. It's the only option I've come up with for scripting out my build.
I'm not sure if you're going about this the best possible way.
I would recommend using a continuous integration (CI) server like Team City that is responsible for deployments. If having the latest version of the source code is a requirement for publishing, then that is probably something you should build into a well-tested CI build configuration, and take away from the hands of the potentially forgetful/occasionally error-prone users.
Since you are wanting to publish using MSBuild and not Visual Studio, I assume you are publishing from a build server or using some sort of script. You can use the Set-ProjectFilesClickOnceVersion PowerShell script to both set the ClickOnce Application Version as well as force the Minimum Required Version to be the latest version. You would want to do this before running MSBuild. My blog describes in more detail how to setup your build server to accommodate publishing ClickOnce applications.
I have a project I made in Visual Basic 2008 Express. I converted it from someone else's C# project, but it works. It has several DLL dependencies. I went to publish my project so I can install it on another machine and for each DLL, I get an error: "Assembly must be strong signed in order to be marked as a prerequisite." I've done some research, but am not finding a lot and what I have found I don't really understand. What does this error mean? What is the best way to resolve it? One other thing: it took me a LONG time to be able to get all my dll's to reference correctly, so I prefer that the solution has NOTHING to do with moving DLL's around because that will likely break the functionality in my main project.
If you're publishing via ClickOnce, go to the publish page and click on "Application Files". From there you should see a list of your DLL's. Ensure that the ones that are giving you trouble have their Publish Status marked as "Include" rather than "Prerequisite".
What this error message means is that the current publishing settings are going to expect all of the assemblies in question to be present in the Global Assembly Cache on the target machine before installation can take place. Since all assemblies in the GAC must be strong signed, any assembly marked as a prerequisite that isn't strong signed will give you this error.
The workaround is more simple than that:
Go to your project.
Right click and Select Properties.
Go to the Security Tab.
Uncheck Enable ClickOnce security Settings.
Unless you are deploying this application through ClickOnce, you don't need to StrongName your assemblies.
Strongly named assemblies are mainly assemblies which have are signed by a cryptographic key. This is fairly easy to do with Visual Studio and does not require re-ordering of your dependencies.
I'm using non-express Visual Studio so the steps may be slightly different for you.
Right click on the project and select properties
Click on the Signing tab
Check "Sign the assembly"
In the combo box select "<New...>"
Complete the wizard
Rebuild
Check this link out...it has instructions for signing your assembly with a strong name:
MSDN: Signing an Assembly with a Strong Name
To create a strong name just go to the SDK Command Prompt or Visual Studio 200X Command Prompt then type in the following
sn -k sgKey.snk
Refer this link for details
Then associate the strong name to your assembly by running the below command
al /out:MyAssembly.dll MyOldAssembly.dll /keyfile:sgKey.snk
Refer this link for details
This just worked for me after the above mentioned solutions failed:
Remove the reference to the assembly in error, then add it again.
I found my problem to be in the .csproj file
<Reference Include="OtherProjectNothingToDo">
<HintPath>..\..\..\..\Pedidos\XBAP\Pedidos\Pedidos\bin\Release\Pedidos.exe</HintPath>
</Reference>
Then I removed it using notepad and it is okay now.
Using Adam Robinson's solution allowed me to publish, but I found that users could not install the project once it was published, as the end user system would complain of an inability to install, noting hard drive space. As this seemed highly unlikely to be the root cause, I looked further into it.
Apparently the basis for my problem was that one of my references was also referencing a .dll that my project used, but a different version. ClickOnce was not having this, and refused to copy the second version of the .dll to the user's system, citing the version already present. Fixing it so the .dll and the project referenced the same version of the other .dll removed the error and corrected the install problem.
Check that the Target Framework is actually set to 3.5 or whatever framework you want to target. Sometimes it will error out when it's not set properly.
I just had this problem too. In my case the blabla.dll was referenced in my solution but blabla.dll was also used in another.dll which i had referenced in my project.
On checking the versions of both blabla.dll they were not the same. So i updated another.dll with the correct blabla.dll and then referenced the new another.dll in my solution. The error was gone.
In short: i was using 2 versions of blabla.dll
I hope this makes sense, if not let me know. :)
Check my blog for more detailed explanation:
Blog article
Regards, Jacob Iedema