I can specify the SkipPostSharp constant to ensure a project is excluded from the list of projects PS processes. I want to do it the other way around though. I want PS to assume it shouldn't process anything that I don't specifically tell it to.
Is this achievable?
There are three conditions for a project to be automatically processed by PostSharp:
PostSharp has been installed using the setup program.
The project has a reference (direct or indirect) to PostSharp.dll.
The MSBuild property SkipPostSharp is different than true and the compilation symbol SkipPostSharp is undefined.
The third condition is what becomes false when you disable PostSharp by checking the option in VS project properties.
You could disable PostSharp by default by setting the SkipPostSharp=True property by default. This can be achieved by creating a file named PostSharp.Custom.targets in one of the parent directories of your projects, with the following content:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<SkipPostSharp Condition="'$(SkipPostSharp)'==''">True</SkipPostSharp>
</PropertyGroup>
</Project>
Then, in every project where PostSharp is actually needed, you would need to define the property SkipPostSharp=False. You will have to do that using a text editor, because the project property tab only allows to set the property to True or to undefine it.
Related
I created this project https://github.com/RemiBou/RemiBou.CosmosDB.Migration, for working it needs the user to do 2 things : create the appropriate folders and edit the csproj so the file inside those folders are embedded.
Before we could do that automaticly when installing with install.ps1 but this feature has been deprecated. Do you know any way how I could do this ?
install.ps1 isn't exactly deprecated, but it's a feature unique to packages.config. PackageReference has no concept of install as anyone can simply edit the csproj and add a PackageReference. When you restore, NuGet has no way of knowing if this is the first time the package is restored for the project after the reference was added, or if it's just the first time the project was restored with a clean repo (after a "msbuild /t:clean" or "git clone", for example).
I don't know an alternative for creating the folders other than having documentation that says the convention is to use that folder name. But, an alternative to modifying the csproj is to take advantage of the fact that MSBuild is a generic build system and NuGet packages can include MSBuild props and targets file.
In your specific case, I would create a props file that defines a property something like <RemiBouCosmosDBMigrationPath>CosmosDB\Migrations\</RemiBouCosmosDBMigrationPath>, which allows your package users to change the property to a different path be overwriting the property value in their csproj, if they prefer.
Then create a targets file which contains a target something like
<Target name="RemiBouCosmosDBMigrationsEmbedMigrations" BeforeTargets="???">
<ItemGroup>
<EmbeddedResource Include="$(RemiBouCosmosDBMigrationPath)**\*.js" />
</ItemGroup>
</Target>
You'll need to figure out what the best target name to put in the BeforeTargets attribute, but I hope you understand the idea. A csproj file is nothing more than a MSBuild file with certain conventions. MSBuild files can import other MSBuild files, and MSBuild and NuGet work together to allow MSBuild to import MSBuild files that come from restored packages. Just compose the MSBuild properties and items in a different way, and the end result can still be the same.
I'm trying to create a "Java/AspectJ application" run configuration for my Maven built project. Because i'm using Spring aspects i have to include the spring-aspects artifact in the run configuration's Aspect Path list. I'm adding it via the "Advanced.." button selecting "Add Classpath variable" and extending from the M2_REPO variable. So in the end i have a classpath variable entry in the list like this with a blue dot icon next to it:
M2_REPO/org/springframework/spring-aspects/3.1.3.RELEASE/spring-aspects-3.1.3.RELEASE.jar
However once i save it, Eclipse automatically replaces it in the launch file with the real path of the JAR on my machine making impossible to share the launch file with others since it's hard coding the entry to my environment.
Editing the launch file by hand doesn't help either because once i run it Eclipse replaces the expression the same way as above.
Is there any way to solve this?
The solution was to create the entry under the "Aspectj Load-Time weaving application" run configuration category instead of the "Aspectj/Java Application". For some strange reason the path of the Aspect is kept in it's unresolved format only with the first run configuration type. I guess it's a bug.
Obviously this makes the launch time longer because it does the waving in run time aswell. However i can't seem to find other solution.
When I build my project from the command line with Maven, I can pass in a property using
-Dsomeproperty=true
For example:
mvn clean package -Dsomeproperty=true
How do I do the same when building in Eclipse?
You have to do the following steps (and sorry, I have no environment to prove it, just from documentation):
Create a maven build by choosing on the selected pom of your project Run > Maven...
Enter the relevant goal, and press add in the arguments table.
Enter there your system property as name: someproperty and value: true.
Then start your maven build by pressing Run.
See the following resources for details:
Creating a Java application launch configuration
Set System Property for JUnit Runner (Eclipse) to test a Spring Web App
After having access to an Eclipse again, here are some screenshots:
The first shows how to configure an existing build (in Eclipse named a run configuration) with the relevant property. and the second shows the command that is then triggered (with the include -Dsomeproperty=true).
I do not know if there is an easy way to configure the default run configuration. You may provide an empty one, enter there the parameter, and copy then that run configuration adding the additional parameters later. The copy button is on the left top the second one (with the red rectangle marking it).
I ran into an issue recently with NuGet restore. I added a project dependency (in this case PostSharp) and then enabled restore. I checked in the source, but not the /packages directory (as I shouldn't needed to....right!). When TeamCity or another developer grabs the source and runs MsBuild, they receive the following error:
C:\TeamCity\buildAgent\work\e374975c0264c72e\ProjectName\ProjectName.csproj(70, 3): error MSB4019: The imported project "C:\TeamCity\buildAgent\work\e374975c0264c72e\packages\PostSharp.2.1.5.1\tools\PostSharp.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
The problem is, NuGet hasn't run yet to restore/download PostSharp or it's .targets file. This feels like a NuGet bug to me, but wanted to see if others have this same issue.
Anybody have this issue or know the resolution. Yes, I could check-in the /packages directory, but then why use NuGet at all?
Another approach is to modify the <Import> element in question, to make it conditional, e.g.:
<Import Project="$(CodeAssassinTargets)" Condition="Exists($(CodeAssassinTargets))" />
This depends on a new property defined in an earlier <PropertyGroup>. I usually add one at the top of csproj file with other "global" flags, e.g.:
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<CodeAssassinTargets>$(SolutionDir)packages\CodeAssassin.ConfigTransform.1.1\tools\CodeAssassin.ConfigTransform.targets</CodeAssassinTargets>
<AutoParameterizationWebConfigConnectionStrings>false</AutoParameterizationWebConfigConnectionStrings>
<UseMsdeployExe>true</UseMsdeployExe>
</PropertyGroup>
Then in an appropriate target, like BeforeBuild, give a helpful error message:
<Target Name="BeforeBuild">
<Error Text="CodeAssassin.ConfigTransforms target is missing. It needs to exist at $(CodeAssassinTargets) in order to build this project!" Condition="!Exists($(CodeAssassinTargets))" />
</Target>
With these modifications, the project will load even if the nuget package restore has never been done. If auto package restore is enabled, the first build attempt should clear up the missing target issue, but if it does not, one manual package restore will.
#porterhouse91, have you checked your csproj file to make sure it has been set up with the appropriate build target?
I haven't yet tried the new built-in Package Restore feature, but I'm assuming it works at least somewhat like the previous workflows out there on the interwebs. If that's the case, enabling Package Restore in your solution only affects the projects in your solution at the time you enable it. If you've added a new project (having NuGet dependencies) to the solution since enabling Package Restore, you're gonna need to enable it again.
Another possibility: the previous workflows involved having a .nuget folder that you needed to check in to VCS, so you might need to check that in if it hasn't been checked in yet (if the built-in Package Restore feature does indeed use this approach).
BTW, if this answer is at all helpful, thank Stephen Ritchie -- he asked me to give it a shot for you.
I had a problem like this as well, but I was able to modify the .targets file in the source package to work around it. Basically, RestorePackages is a build target that runs when the project is built. Unfortunately, the package won't even load properly before the imports are satisfied. The only way I know to fix this is to include the .targets file as content and then change the BuildDependsOn property so it restores the packages before it runs your custom tasks.
<PropertyGroup>
<BuildDependsOn Condition="$(BuildDependsOn.Contains('RestorePackages'))">
RestorePackages;
CustomTarget;
$(BuildDependsOn);
</BuildDependsOn>
<BuildDependsOn Condition="!$(BuildDependsOn.Contains('RestorePackages'))">
CustomTarget;
$(BuildDependsOn);
</BuildDependsOn>
</PropertyGroup>
To be clear, this doesn't help with pre-built packages, but if you can build the package again yourself, you can fix it.
I ran into this same issue with Visual Studio 2012 and NuGet packages not checked into source control.
The error:
The imported project "\packages\Microsoft.Bcl.Build.1.0.7\tools\Microsoft.Bcl.Build.targets" was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
I found a msdn writeup on the situation that gave the following workarounds for grabbing a project from source control without the NuGet packages.
Stop using package restore and check-in all package files
Explicitly run package restore before building the project
Check-in the .targets files
I decided to go with option #2, however, NuGet currently (v2.6) does not include a way to install all packges from the packages.config file from within visual studio. Some searching revealed that you need to use the NuGet Command Line to execute the following command before opening Visual Studio (reference).
c:\path\to\nuget.exe install -o packages project-folder\packages.config
I'm developing a JavaEE system with several applications which consists of many projects (EARs, EJBs, etc).
Whenever I change my runtime target of the Enterprise Server I have to reconfigure each project through Eclipse's wizards, and this takes forever.
For now I use a little script which updates the runtime target manually, although it says here:
The target runtime environment is specified in the org.eclipse.wst.common.project.facet.core.xml file in the project's .settings folder. You should not edit this file manually; instead, use the properties window as described in this topic.
Why am I changing the runtime target name?
1. I've upgraded the runtime target.
2. Another member of my team co the code from the SVN and he has a different name for the target runtime.
Is there a way to configure the projects to run with a default runtime target, which can be easily configured?
Possible workaround for 2: remove the org.eclipse.wst.common.project.facet.core.xml from SVN and put its name in the svn:ignore property.