I work in a codebase where for historic reasons not all projects have identical coding conventions. In fact, within a single .sln I have projects requiring different naming conventions.
Is there a way to have resharper use different settings based on which project the file I'm editing lives in?
Since ReSharper 6.1 you can finally have per project settings!
Basically, all you need to do is to create a file named <project file name>.DotSettings, e.g. MyUnitTest.csproj.DotSettings.
See this blog post for more info.
Check out the Resharper Settings Manager tool
You'll need to first install the ReSharper Power Toys to use it.
Resharper now supports applying different settings to different Solutions from Resharper 6.1. See this blog post for further details http://blogs.jetbrains.com/dotnet/2011/11/resharper-settings-in-61/
However, from the looks of it, you cannot yet apply different settings to different projects within a solution. This is a feature I would very much welcome too!
Additionally (to the other answers) when using SVN the "*.sln.DotSettings" files are changed every time a different machine opens the solution. To combat this set the read-only attribute on the DotSettings files, after checking out from the repository.
Related
Ever since I've been using the (relatively) new .NET Standard Library project type in Visual Studio, I've been having some problems getting a complete set of DLL files that are required by my project.
The problem is usually limited to 3rd-party libraries which I reference as NuGet packages. I've noticed that these don't get copied to the output folder of my project when I build it. This didn't use to be the case in classic project types.
While I can appreciate the de-cluttering effect that this change has brought for .NET Standard projects, I'm now faced with a problem. I sometimes absolutely need to be able to get the entire list of all files that my project depends on!
I have several different cases, where I might require this list for one reason or another, but the one I believe is most crucial for me, is when I want to gather these files from the csproj itself, right after it's built. In there, I have a custom MSBuild <Target> which should take all the files from the output dir and zip them together for distribution. The problem is, I'm missing all the files that come from NuGet dependencies, because they're not there!
How can I solve this in a general (i.e. not project-specific) way?
UPDATE
There's this deps.json file that contains basically all I'm after and then some. It's just a matter of extracting the relevant information and find the files in the local NuGet cache. But that would involve writing a specialized app and calling it from my target. Before I start writing one myself... Is there something like this already out there somewhere?
I followed this answer and it sort of works.
The suggested thing was to include the following into my csproj:
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
My main concern is that it also outputs some other DLLs from the framework (such as System.Memory.dll and System.Buffers.dll, among others), which I didn't expect. But maybe that's a good thing. They do seem to be dependencies, just not direct ones. I'll see how it plays out.
If it turns out ok, my only wish would be that this directive was more prominently displayed in project settings (as a simple checkbox, maybe?) so I wouldn't have to hunt the web to find it.
Due to the wording (many meanings of "extension" and "method"), I am utterly unable to find any information about my question on the interwebs. So I am asking here:
Is it possible to deploy "extension methods" with a VSIX extension?
Clarification:
By "extension method" I mean something like
public static string SomextExtension(this string s, string p) {
retrun s + p;
}
By VSIX extension I refer to a custom extension, that gets installed via a
SomeCoolExtension.vsix
The goal is:
A user installs the VSIX, gets a few features (mainly custom code generators in my case) and additionally has access to "Hello".SomeExtension(" World"); within their source code.
I am slowly thinking this just isn't possible as I have tried everything I could come up with and as stated in the beginning, it is virtually impossible to search for it on googls.
If it really is impossible, I would at least love to understand why.
So a simple "no" might be a valid answer, but if you could elaborate, that would put my coding soul to rest :-)
Specs: I am using VS2017 and the new "Visual Studio AsyncPackage", but if you know an answer for older version, I sould be happy to try them.
You can use both approaches:
An extension (.vsix) provides the greatest flexibility, because it can provide commands (buttons on menus, context menus and toolbars) that, on demand by the user, can 1) Insert code in the active document 2) Add files with code or other assets 3) Add references to Dlls that the extension can deploy in the source folder of the project, etc. Also, it can do all that not only on demand, but automatically watching events and examining if some conditions are met, for example, a solution is created, or it is loaded, a project is added, it already contains a code file or not, it already has a reference or not, etc. Needless to say, all this flexibility comes from some complexity.
A NuGet package can add DLLs to the references or code files to a project, it can execute a PowerShell script when the NuGet package is added to a project that can modify the project, it can modify the build process adding new MSBuild targets/tasks (being the Microsoft.VSSDK.BuildTools NuGet package to create a VSIX extension the prime example). It is a one-time operation during installation on a project. After that, no events, no commands, etc. but for most scenarios is much simpler.
I am currently setting up TeamCity for my company's .Net solutions, including the Inspections (.Net) runner.
I have it working but would like to change the naming conventions it looks for, as my current company code standards have a m instead of a _ before private field. I know it is possible with the full version of resharper (here), but I was wondering if it was possible to change this within TeamCity?
Many Thanks
Andy
"Inspections (.NET) runner" in TeamCity is the same thing as "ReSharper CommandLine Tools" is. So, I guess, "Introducing InspectCode" article will help you to adjust needed settings.
Well, if you want to configure InspectCode on a TeamCity server, you can make all configurations locally with ReSharper, save the settings to the Solution Team-Shared layer, and then commit the resulting {SolutonName}.sln.DotSettings file (this file is stored in the root directory of the solution near .sln file) in your VCS. InspectCode on the server will find and apply these settings.
As an alternative, you can configure InspectCode by specifying a shared .DotSettings file through the /profile (/p) parameter.
I have a c# ClickOnce application that I need to be able to publish multiple times for OEM purposes.
The way I understand it now is that publish settings are located in the .csproj file.
However, this is inconvenient in the case where I want to publish multiple versions.
for example, Company A needs totally different icons, start menu location, product name etc. from Company B, but the assemblies need not be renamed.
Here are a couple approaches/questions that I can think of to solve this issue...
1.Is there a way to create a separate publish settings file to use during build time?
2.Can I edit specific publish settings (like Start Menu location, etc) at build time with MSBuild.exe? I think this would be ideal...
e.g.
MSBuild.exe project.sln /target:Publish /property:edit-project-publish-settings-here
3.Maybe create a 2nd .csproj file? (Would prefer not to do this...)
Please share your thoughts as to the best approach, or any other clever ways to make this happen. Thanks!
I wish I could give you some brilliant solution, but personally I would probably go with option 3.
I mean, its pretty simple, the changes should be pretty static and it will be difficult(ish) to totally screw it up and deploy the wrong changes to the wrong company.
If you copy the .csproj in your project folder, it will reference all of the same source files and you can just change the executable name. Create another VS solution and you can reference the copied .csproj and get rid of your first one so that you can publish two separate versions.
This isn't ideal for ClickOnce however.
If you use a Singleton object that specifies the "mode" (Company A, B, C, etc.) you can easily store that in the app.config (or another xml file). Then just re-publish your ClickOnce Application but copy the correct version of your configuration file in so it gets shipped with the build. This way, you don't need any additional csprojects Just include all of your icons and set them at run-time on App Start based on your Singleton object.
I found that you are able to edit certain properties using MSBuild.exe like this
MSBuild Solution.sln /target:publish /property:ProductName=ProductA\;Publisher=CompanyA\;ApplicationIcon=companyA.ico
I found another useful post on modifying.csproj files programatically with .NET code. (This would only be needed if you're modifying things that are deeper than just the project properties specified in the ClickOnce documentation below)
The MSBuild documentation here was also useful -- especially under Publishing Properties
We have a fairly hefty VS2008 solution that comprises of many library projects that are referenced by one or more other projects. Some of these libraries define things like WCF bindings and connection strings, but when these are referenced by other projects, it seems to become a necessity to copy the binding settings from the library projects' .config files into the executable projects. It seems like we're missing something here as this approach has started to violate DRY principals in a major way with duplicate settings littered throughout the solution. Changing a binding has become a major exercise in search & replace.
I have looked at the this project on CodePlex as a possible solution, but I wonder if we're misunderstanding the principals behind app/web.config files.
Is there an easier way?
Not really no.
In sufficiently large projects you end up with settings that need to go in several projects.
One solution I've used previously is to have a custom task run on post-build to modify the configs to set a specific variable (say '$generalSettings') with a bunch on common things, from a local file I call 'local.deploy.properties'. I use NAnt to do this.
These days, I use a custom solution I've written to do it (though it combines the approach above anyway, due to the need to test locally).
Anyway, what I'm getting at is this is a generally unsolved problem.
You have to automate settings propagation in order to keep things working properly. This can be done by adding batch copy command in post-build actions. You can find this settings in the project properties menu.
In order to customize copied settings for a specific project the XSLT transform can be used.