When Visual C++ builds (vcxproj) file form Visual Studio or you build it by means devenv (building sln), then you get log form the build of the vcxproj in file specified by item BuildLog.Path.
Default value of this item is $(IntDir)\$(MSBuildProjectName).log
I’ve actually find this feature really useful for post build analysis per project.
I’d like to simulate this behavior by building just from msbuild.exe.
There are serious build automation reasons why I cannot use devenv now(as far as I’m aware I cannot build vcxproj by devenv without sln).
I've tried to resolve this problem by:
creating custom target that determines value of BuildLog.Path and returns it back
and then execute task Exec with msbuild commandline including argument that use filelogger to create log file
Problem is that it does not work!
There is an interesting thing that the default is specified by:
<ItemDefinitionGroup>
<BuildLog>
<Path>$(IntDir)\$(MSBuildProjectName).log</Path>
</BuildLog>
</ItemDefinitionGroup>
If I understood correctly this specifies metadata path for each BuildLog item.
By default there is no BuildLog Item (because there is no Include in vcxproj –for BuildLog Item).
Does anybody has solution for this problem or can explain how to solve it?
determine BuildLog.Path metadata or
build vcxproj file just by msbuild with logging file to log file specified in vcxproj or inherited from props file
Related
enter image description hereI want to create model: add > class > ado.net entity, for my db first project and also want to create CRUD operation by asp.netscaffolding, but failed to create a model with necessary code.and thus i failed to create scaffolding .
in my model file AllahHelp.Context.cs, there is no code, only the text "ErrorGeneratingOutput".
Error 1:
A namespace cannot directly contain members such as fields or methods F:\project\WebApplication8\WebApplication8\Models\AllahHelp.Context.cs 1 1 WebApplication8
Error 2:
Compiling transformation: Metadata file 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools..\IDE\EntityFramework.dll' could not be found F:\project\WebApplication8\WebApplication8\Models\AllahHelp.tt 1 1 WebApplication8
If there is an error transforming your .tt files into class files, your class files will just have "ErrorGeneratingOutput" in the source file, which causes a "namespace cannot directly contain members such as fields" error, but doesn't really have anything to do with that.
Your actual error sounds like you're missing a reference to EntityFramework.dll. Right click the project, choose "Manage NuGet Packages..." and find and install EntityFramework to your project.
In some situations I've also run into a problem where since the transformation occurs before files are copied, referenced dlls don't ever get copied since the error occurs and stops the process. In this case you would need to remove the model from your project temporarily, successfully compile the project, and then add the model back.
According to this similar question it could also be because of your install path. If that is your issue, try to find where the dll is, and correct the environment variable VS120COMNTOOLS (Control Panel -> System -> Advanced System Settings -> Environment Variables -> System Variables)
(Be careful changing system variables, though.)
I was getting this error when attempting to build a project using .tt templates. I fixed the issue by checking everywhere that I used C# code injection and making sure that I closed each section of C# code by including #>.
Example:
Problematic code:
{
"find": "__LOCATION__",
"replaceWith": "<#= deployment.Location"
},
Fixed code:
{
"find": "__LOCATION__",
"replaceWith": "<#= deployment.Location #>"
},
My project is a mvc4 project in visual studio 2013 ultimate.
I tryd to send my project by following the steps :
File > Export template > (leave all the options as default)
I get a zip that i unpack. If i open the unpacked solution and run the program i get alot of errors. It looks like visual studio replaced all the text that contained the projectname with $safeprojectname$. How can i export the project without visual studio replacing all the 'projectname' spots so that i can run my program.
I tryed creating a new project (console application) with no code in it, if i export it and import it i get the same message first i get :
Warning 1 Load of property 'RootNamespace' failed. The string for the root namespace must be a valid identifier. SvenEind
and after running i get
190 errors 31 warnings
I tryd importing http://www.asp.net/mvc/tutorials/getting-started-with-ef-5-using-mvc-4/building-the-ef5-mvc4-chapter-downloads and that worked for me.
So i guess the problem is in some kind of settings for exporting files.
replaced all the text that contained the projectname with $safeprojectname$
This is very much by design. You created a project template, a cookie-cutter for new projects. You are not supposed to do anything with the .zip archive. It should sit patiently in your "My Exported Templates" folder. Until the day arrives that you want to start a new project.
You then can pick the template instead of using one of the built-in ones that were preinstalled by the Visual Studio installer. Visual Studio prompts you for the project name. It then unzips the archive, copying the files into your new project directory. And modifies the files, $safeprojectname$ is substituted by the new project name you entered. You now have a good start for your new project, using the settings and assets that you saved earlier when you created the template.
Sounds like you had an entirely different use in mind, I can't guess at the intention from the question.
Hmmm. I got this error on Build:
The app manifest must be valid as per schema: Line 42, Column 18, Reason: '$safeprojectname$' violates pattern constraint of '([A-Za-z][A-Za-z0-9]*)(\.[A-Za-z][A-Za-z0-9]*)*'. The attribute 'Id' with value '$safeprojectname$' failed to parse.
So I grabbed the project name from the VS Configuration Manger and put it in the app manifest like this.
<Applications>
<Application
Id="CordovaApp.Windows10"
And the error went away and the project built. HTH.
I'm using Visual Studio 2012 to build a empty SharePoint 2013 project (added a test list). However when I try to deploy the project I receive the following:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SharePointTools\Microsoft.VisualStudio.SharePoint.targets(418,7): error MSB4131: The "IsDebugging" parameter is not supported by the "SetPackagingProperties" task. Verify the parameter exists on the task, and it is a gettable public instance property.
I've tried commenting out various lines but it just leads to more problems. Furthermore it then does not package the solution.
The setPackagingProperties task, as documented here http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.sharepoint.tasks.setpackagingproperties.aspx, indeed does not include a IsDebugging property. Therefore is the file C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SharePointTools\Microsoft.VisualStudio.SharePoint.targets incorrect? I'm using SharePoint Found Server 2013.
Thanks for any help - this one is doing my head in!
Turns out that the solution was simple: a conflict of DLLs.
To anyone else with the same problem:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SharePointTools\Microsoft.VisualStudio.SharePoint.Tasks.dll DOES contain the IsDebugging property (undocumented!). My problem was that I had VS 2010 installed with the SP developer tools. This meant that VS 2012 was referencing the incorrect DLL version of Microsoft.VisualStudio.Sharepoint.Tasks.dll. My solution was simple to therefore search the entire system for this DLL and delete all copies apart from the one referenced in the path above.
Pareto's ratio: 80% of time wasted is attributable to just 20% of problems encountered, like this one!!!
I am Using CC.Net to run an .exe file after project build is complete and need to pass the project name, publish date/time and user on the command line as parameters to the .exe. However I can't get cc.net to recognise these a dynamic properties and replace them with the correct values.
<publishers><exec executable="C:\MyApp.exe"></exec><buildArgs>"$[$CCNetProject]" "$[$CCNetBuildDate]" "$[$CCNetBuildTime]" "$[$CCNetUser]"</buildArgs><buildTimeoutSeconds>30</buildTimeoutSeconds></publishers>
The correct syntax for properties in ccnet config is $[CCNetProject]
I believe the correct syntax for properties in ccnet config is:
$[CCNetProject]
Rather than:
$[$CCNetProject]
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Pre-build task - deleting the working copy in CruiseControl.NET
I would like to delete my working directory during the cruisecontrol build process...I'm sure this is easy, but I have been unable to find an example of it...
If you know how to create a directory, that would be useful as well.
Thanks.
One of two ways.
If you're already using an MSBuild file or something similar, add the action to the MSBuild file.
Instead of directly executing some command, create a batch file that executes that command and then deletes the directory, and have CCnet call that batch file instead.
My guess is that you want to delete the working directory before CruiseControl.NET gets the latest code from source control. If this is the case, then the only way to accomplish this is to write a custom source control provider for CruiseControl.NET that first deletes the working directory and then gets the latest code. Have a look at CruiseControl.NET's source code for examples of how to write a source control provider.
If you want to delete the working directory after the latest code is retrieved from source control, then you can use CruiseControl.NET's executable task by running "cmd /c del directoryname".
In the ASP.NET work, for me, the easiest way I do it (which allows me to hit either MSBUild or NAnt depending upon the project) was to roll my own exe that takes an argument which I pass in with a bat file fired by CC.NET. It's not the safest thing in the world, but if you have total control over your automated build machine; it's not too shabby. Quick and reusable.
Drop in the exe somewhere that does the recursive delete:
static void Main(string[] args)
{
for (int n = 0; n < args.Length; n++)
{
if (Directory.Exists(args[n].ToString()))
{
Directory.Delete(args[n].ToString(), true);
}
}
}
Drop it in somewhere multiple files can pass arguments to it and just write a custom .bat file for each project. So my task block looks like this:
<tasks>
<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable>
<workingDirectory>Z:\WorkingDirectory</workingDirectory>
<projectFile>YourSolution.sln</projectFile>
<logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
<exec>
<executable>Z:\SomePathToBuildScripts\YourCustomBat.bat</executable>
</exec>
</tasks>
Then the final step is setting up that .bat file to perform the delete/rebuild functions after use. In the bat file just make sure you rebuild ("MD") the directories you deleted if youexpect to publish a site back to them. On our dev boxes I found this to be the best way to prevent the beloved Frankenbuild.
The way I've done this in the past is to not have CC.Net checkout source itself. Instead, there are two <msbuild> elements for the project, the first one calling a build target that runs svn-clean.pl (compiled to .exe), and then updates the source using svn.exe. The second <msbuild> element starts the main build process.
You can easily replace svn-clean with a delete command. For my projects, deleting chaff from a checkout has always been faster than checking out a fresh working copy.
The two msbuild elements are necessary because the main project build file is often updated. This is important because updates to your build file(s) will only be reloaded if you start a new msbuild process.
This setup breaks down when I (very rarely) move or change the dependencies of that clean-and-update build target to the extent that the msbuild process would need to reload for valid instructions to run the clean-and-update target. When this happens, I stop CC.Net before committing, go into the CC.Net server, and do an 'svn update' by hand.
Sidelight: It could well be that CC.Net has a natural clean-before-build operation by now. I've since moved to TeamCity, which is configurable to do this every build or only when the developer chooses (e.g., when you know you've made a change that would not update cleanly--svn moves of directories with build products comes to mind).