I have a windows application and using cheetah for config transformations i.e app.config.debug, app.config.test, etc.,
When the project is built in debug mode , it works fine but when teamcity change the mode to test configuration and try to rebuild getting the following error:
/platform:anycpu32bitpreferred can only be used with /t:exe, /t:winexe and /t:appcontainerexe
Can anyone please help me how to fix this?
Thanks
Open the project file with the text editor. Find the line <Prefer32Bit>true</Prefer32Bit> and change the value "true" to "false". There might be more than one depending how many different configurations have been set up.
Removed true from one of the project. It worked.
But not sure how this entry was added to that particular project.
For me the issue was that the project listed in the error had the wrong configuration setup. So while the Configuration Platform for the current build was set to x86, the target platform in the properties for the x86 configuration was set to AnyCPU.
So for OP sounds like the configuration is correct for the Debug build, but your target platform may not match the platform specified in your test configuration profile.
If you experience this issue please check that the target platform in the build properties for your project match the configuration platform.
I've noticed that when Visual Studio 2012 loads/initializes projects (when opening a solution or when changing platforms/configurations), it may execute some MSBuild targets - those that are listed as InitialTargets (it doesn't always do that - sometimes it waits until you actually build it; I can't figure out when exactly, but that's a different question).
Anyway, these targets may generate some output in the form of MSBuild messages. If the targets were being run as part of a build, these messages would go to the output window of Visual Studio (and perhaps a log file). These "load-time targets", though, do not seem to send their output to the output window.
How can I see or log the output of MSBuild targets which execute outside of build time, and specifically in initialization time?
The best information source from the MSBuild team at Microsoft I could find is dated (2005), but may still be actual if no one could come up with fresher information:
The project load logger is used when projects are opened. It discards all messages logged while the project is opened, puts warnings in the error list, and displays any errors in a message box to the user. The errors displayed are quite detailed and useful in helping diagnose project file formatting issues.
When I try to run codecoverage tool on release bits of my website I get an empty .coverage file containing the following error:
Empty results generated: No binaries were instrumented. Make sure the tests ran, required binaries were loaded, had matching symbol files, and were not excluded through custom settings. For more information see http://go.microsoft.com/fwlink/?LinkID=253731
This issue does not occur if I run it on the debug version of the same build.
These are the exact steps I perform:
- start monitoring code coverage on IIS server
codecoverage collect /IIS /session:test /output:test.coverage
- perform a few click around the website
- stop monitoring code coverage
codecoverage shutdown /session:test
Note! I do hae the .pdb files in the same place as the binaries.
Any ideas?
Thanks,
Cristina
I finally managed to get to the bottom of this. For the release build, there were 2 things I needed to change in the .config file
specify the path to the Symbols (apparently this is needed even if the .pdf files are in the same location as the dlls)
I had to remove the default exclusion list since these included Microsoft public key tokens and our product is a Microsoft product.
Hope this will be helpful for others running into the same situation.
Regards,
Cristina
Try this: Enabling Profiling.
[UPDATE 5 Jun 2013 14:04:00-04:00 UTC]
I also found this article that you may be interested in: Application Analytics: What Every Developer Should Know.
As far as Code Coverage is concerned, I didn't see anything specific to using the VS Code Coverage tool and configuring for IIS. I did see lots of articles about testing web applications in general, some of which involved setting up code coverage (Setting Up Machines and Collecting Diagnostic Information Using Test Settings being an example).
Sorry I couldn't be of more help to you.
I just deployed a website into IIS 7 (about which I am woefully ignorant), and upon trying to build the site, I receive this error. I did a little googleing and I saw an article that said I should put system.web.extensions.dll into the /bin. But, I also saw an article saying not to do that. I tried it anyway, but I just received a different error ('Resource cannot be found').
I am totally clueless as to what else to try
Can you use the "Publish" command in Visual Studio to publish directly to the site? If not, then use that command to publish to a similar site on your machine, then copy it to the customer site.
You should also look into the IIS Web Deployment Tool. It can copy an entire site, including IIS settings and any databases. It will be built into VS2010.
Go to control panel, then programs, turn windows features on or off, scroll down to Microsoft.net framework 3.5.1 expand, make sure both sub options are selected, this might help your issue.
Can anyone suggest the best deployment approach for VSeWSS 1.2 based development?
I have been working with this for more than 6 months now.. has anyone tried using WSPBuilder for this purpose?
I Personally prefer using stsdev (http://www.codeplex.com/stsdev). I've used both WSPbuilder and STSDEV. Stsdev offers some development project templates that you create using an stsdev gui, not like the standard project templates you create using new > project.
The stsdev projects has got a Rootfiles folder, which corresponds to the '12 hive' on the destination server. All the files you put into Rootfiles folder and subfolders, is automatically added to solutionpackage.ddf and manifest.xml, so you dont have to worry about editing these files and compiling them using makecab.
Another great thing that stsdev offers is build targets, like build, deploy, redeploy, Refresh Assembly in GAC, retract and upgrade. So stsdev projects automatically compiles the binaries, builds the .wsp package, and runs the stsadm commands according to the build type. You can customise the behavior of the build targets if you like, by editing the Microsoft.SharePoint.targets located in the DeploymentFiles folder of the project. As long as you are only working on the code, Refresh Assembly in GAC is a very fast build method, and you can see the changes in sharepoint immediately after.
An disadvantage of stsdev is if you use source control, the manifest.xml and SolutionPackage.ddf if not checked out, are read only, and will result in a compile error (i usually check out all the files in DeploymentFiles folder when working on a project). So you have to check out these files before building. Another thing is that it takes all the files under the Rootfiles, including the hidden vssver2.scc files if you are using source control. The project still builds and deploys without problems, but the files are in the wsp package, and copied to the '12 hive' on the destination server.
I think that compared to WSPbuilder, stsdev lets you customize just about anything of the development project, which i haven't been able to do in WSPbuilder.
You should do yourself a favor and look at VSeWSS 1.3. See Kirk Evans' blog for a good video overview: http://blogs.msdn.com/kaevans/archive/2009/03/13/sharepoint-developer-series-part-1-introducing-vsewss-1-3.aspx.
Major downside could be that it requires Visual Studio 2008.
I have been a STSDEV advocate, but am now leaning towards VSeWSS 1.3. My suspicion is that other WSPBuilder and STSDEV users will feel the same over time, but I haven't finished my evaluation of it yet.
We have always used WSPBuilder. This is best if you are looking to create wsp's.
It also provides a VS Add-in. You can build, deploy, upgrade etc. right from VS. Provides VS templates like Blank features, Web Part Feature, Feature with Receiver, Workflow feature, Event Handler, Item Template etc...
We manage 20+ projects with WSPBuilder
As Kirk Liemohn points out, you really should upgrade to VSeWSS 1.3. We took lots of customer feedback and there's lots of new features for developers in this version.
It includes quick deploy commands for deploying just the new binary or just the files into the SharePoint 12 folder structure. It also runs on x64 OS with Visual Studio 2008. It has command line support.
Available here
I prefer WSPBuilder as well. I don't have any problem with not being able to configure WSPBuilder the way I want it. In the latest version you can override its settings for each project or developer individually should you want to.
There is also a great add-on to WSPBuilder called SPVisualDev (codeplex.com/spvisualdev). Among other features it provides templates for adding ASCX files and it automatically pushes down files you have put in your project 12-hive folder from VS into the real 12-hive folder.. A huge time saver for me.
One downside to VSeWSS 1.2 was the lack of deploy to bin support. 1.3 adds that, but I haven't gotten it to work with referenced assemblies.
I've switched to STSDev 2008, a spinoff of the original STSDev with bug fixes. I've been working with the main contributors to add documentation to the project on CodePlex, but it's had 1900 downloads in little over a year.
I have used VSeWSS 1.2 and 1.3 and it does make deployment pretty easy. The question I had was, what do you guys usually do if you wanted to distribute the Web Parts to a customer administered SharePoint server.
Do you just take the Release folder and tell them to run the setup.bat script? Do you package it differently? Do you create custom installers?
VSeWSS 1.3 CTP is out now, and does have command-line support. That being said, the extensions are IMHO--and based on currently using them for a very large, very complex project--a pain in the rectum for the following reasons:
Every time you open a solution of extensions-enabled projects, you will have to sit and wait while the VSeWSS wheedles through each and every project, checking structure and trying to repackage each solution. The wait seems to grow exponentially with every extensions-enabled project you add to the solution. Given all of the waiting already included in doing SharePoint development inside a VM, the wait can be excruciating.
While VSeWSS is making its way through the projects, no indication is given of any work going on; VS simply becomes unresponsive.
Every time you close your VS solution with extensions-enabled projects, VSeWSS does the whole operation over again. Given that, by this time on my current project I'm usually 10 or so hours in the seat, and the last thing I want to do is wait longer to go home, this process is worse that excruciating (if that's even possible.) Most of the devs on our team just go to Task Manager and kill the devenv.exe. process rather than waiting.
We've had a very bad time of it trying to use the current (CTP) version of the extensions to do an integrated build. We've been having a number of problems using VSeWSS from the command line to do build and packaging of all of our projects.
In brief, use STSDEV. Setting up the folders is kind of a pain, but once you have everything scripted out, you're pretty much set.