After much searching and following bread crumbs, it appears that to add a NON ASP.NET assembly as a reference to a ASP.Net project (not in the same solution), one must use DNU WRAP.
I attempted to do so by doing a CD to the solution directory and entering the following line
dnu -v wrap --configuration release -i code/access/access.csproj
The response tells me that I am missing NuGet packages and to 'enable NuGet Package Restore'. I had (and rechecked) already done so.
Searching the internet for 'dnu wrap' returned 2 hits on GitHub with the more interesting one being a side discussion of dnu wrap needing a global.json at the solution level. However, my one ASP.Net solution does NOT have a global.json file.
My questions are
1) what are the steps required to get dnu wrap to work correctly on a Windows system with VS 2015 RC installed?
2) under what conditions must the dnu wrap be redone?
I finally figured out the process. It has changed over the past 10 months since I started on the journey.
See my answer to my question on how to wrap a dll for reference in a asp.net project for a lengthy response.
Related
I am publishing my node js site to azure using this tutorial - http://blogs.technet.com/b/sams_blog/archive/2014/11/14/azure-websites-deploy-node-js-website-using-visual-studio.aspx
I get the following error, as mentioned in one of the comments on the blog, any idea what this error is about and how do I fix this ? I am able to run my app locally no issues with that.
Error: InvalidParameter
Parameter name: index
P.s : the site is like a very basic "Hello world" kind of site, this is the first time I am using and deploying to azure too.
I created a new project as a "Blank Azure Node.js web application", and replaced the resulting package.json and .js files with what I had before, and it publishes fine now
All was working fine for and suddenly got the error! I pretty sure it something in the project as it's now happening on vs2013 and vs2015 on different computers.
Its something to do with Templates after a lot of searching. For me Azure TFS CI got things working again if possible for you?
I had this issue with some projects but not with others, all created in a similar way. So I went thought every change and every setting I could until eventually i worked it out. I didn't want to give up and just remake them.
Basically its file paths, the first thing you notice is that it errors very quickly compared to a usual publish, the first thing that is triggered is a build but unlike heavy framework languages there not really much to actually build.
Like all builds for VS it pops out a bin folder take not of where this appears. This is the key, you want this to appear in the root of your deployment usually at the same level as the publish profile.
Before I moved my projects to VS, TFS and Azure, I used to use git and used the azure push and deployment as part of git, so I instinctively structured my folders in the similar fashion with src folder and all the extra VS baggage in the a directory higher.
This is where I noticed bin folder, so re-structured my solution and made changes to .njsproj (notepad) and moved to be inline with source code and re-added it yo my solution.
Technically speaking this a bug within VS as it allows to create the project and specify different locations which is all fine unless you want to build and publish locally.
Once you get your head around what is going on you should be able to solve this problem easily and not make the same mistake in the future. If anyone is still confused comment and ill grab some screen shots.
I'm trying to run ef7 migration on fresh asp.net 5 preview project.
Steps I took:
Created fresh project based on template "ASP.NET 5 preview starter web"
Build it
Try command Add-Migration in Package Manager console
Result:
The term 'Add-Migration' is not recognized as the name of a cmdlet,
function, script file, or operable program.
I also try this command:
Install-Package EntityFramework.Commands -Pre
I think for VS 2015 project is redundant, it executed but still Add-Migration was not recognized.
Thanks in advance for clues...
NuGet commands don't work with ASP.NET 5 projects. You'll need to use the ASP.NET 5 command-line versions of the commands. (E.g. k ef migration add) We have an issue aspnet/DNX#952 open to unblock this scenario, but it hasn't seen much activity.
To learn more about the ASP.NET Commands, see my post EF7 Migrations: ASP.NET Commands.
Ok, I know this is an old question and it has already been technically answered. That is, if you want to open command prompt and do it. The root cause of this problem is that the PowerShell module is not initializing. There is a simple fix though. You just need to initialize the module. Go to your solution explorer. Go to References >> .NETCoreApp,Version=v1.0 then scroll down until you find Microsoft.EntityFrameworkCore.Tools right click and show the properties. Take note of the path it should be something like
C:\Users\YourUserName\.nuget\packages\Microsoft.EntityFrameworkCore.Tools\1.0.0-preview2-final
Once you have that go to the path location in file explorer. You should see another folder called tools. Inside that folder you will see a .ps1 file called init.ps1. This is the module that we need to initialize. So go back to Visual Studio, I am using VS 2015 pro and Win 10 pro, open the package manager console. Type in the following
cd
"C:\Users\YourUserName\.nuget\packages\Microsoft.EntityFrameworkCore.Tools\1.0.0-preview2-final\tools"
and press enter. Then to initialize a module in PowerShell you just need to type
. .\init.ps1
or I believe you can just do the entire path and get the same results so that way would be
C:\Users\YourUserName\.nuget\packages\Microsoft.EntityFrameworkCore.Tools\1.0.0-preview2-final\tools\init.ps1
Unfortunately you would have to do this every time that error pops up, but its not that bad if you just save the path in a .txt file or comment it somewhere in your project that is easy to find.
this is EXTREMELY frustrating to anyone who just wants to pull down your code and check it out and get it to simple build successfully.
Here's the scoop.
So I open the ServiceStack.Examples-master\src\AppHarbor.sln after pulling it from github and cloning it to my local drive.
I have had nothing but trouble from the get go. I have had to fix this solution and project reference as well as assembly references.
there's nothing more irritating to a developer no matter if it's an internal solution or set of .NET projects or external, that bomb during initial build. This stuff should be building period.
Also when I can't even download an examples solution and get it to build it makes people wonder how well this open source API really is, can I truly even rely on it? This reflects on you Service Stack.
here's is what I did, nothing out of the norm here:
1) Cloned ServiceStack.Examples to my local c:\www\Sandbox folder where I keep stuff I'm playing around with
2) Just looking at the folder structure from the start, it makes no sense in terms of being discoverable and more importantly organized. For example why is there yet another ServiceStack.Examples inside src and then outside of that a ton of other example folders of other example apps in the root of \src also??? So you have stuff in src\ and in src\ServiceStack.Examples, this is hell confusing and disorganized.
ServiceStack.Examples\src\ServiceStack.Examples
3) Opened C:\www\Sandbox\ServiceStack.Examples\src\AppHarbor.sln
4) Tried to build all, and the first major problem is the MovieRest project doesn't load. I get an error while opening the .sln that it failed to load it:
ok fine, this is still ridiculous, nobody who downloads a solution should need to worry about fixin this but of course I did, so I readded it because in actuality this .csproj was moved into the src\ServiceStack.MovieRest\Web\ folder and looks to me like nobody even reopened the solution to fix it??
5) So then I go to try and build the solution again, notice all the missing binary references in MovieRest. So ultimately I figured ok, looks like pretty much every other project is getting their references from their associated packages folder however for some Reason MovieRest and the Nortwind projects don't have anything in their packages folder. so I end up manuall opening up the MovieRest VS 2012 solution and building it, and I guess Nuget must run or something during that build? Because now walla, I see the missing assemblies pop into ServiceStack.Examples\src\ServiceStack.MovieRest\packages finally.
6) Ok, so I rebuild again, and now it's complaining about missing sqllite assemblies and also a sqllite3.exe. So now I have to hunt around again to find them for the x84 and x64 and copy those missing assmblies back into ServiceStack.Examples\src\ServiceStack.MovieRest\Web\sqlite and I also noticed that MoviewRest project was referencing sqllite3.dll in the root of the project which was also missing...this is such a mess.
7) I notice that the Northwind project doesn't build either
I don't know what is going on here, I mean is the build really that messed up? Has to be.
Who is gonna fix this on the ServiceStack end? how the heck do I get this to finally build and how has this not been reported?
UPDATED 9/23
Here are the errors I get after pulling down the "fixed" solution. I did a Shift + Ctrl + B on it (Build All). Let me know if I am just missing something here but it's not building yet at least on my side:
UPDATE 10/1
Ok again lets talk about this.
I pulled this zip down: https://github.com/ServiceStack/ServiceStack/archive/v3-snapshot.zip from this page: https://github.com/ServiceStack/ServiceStack/releases
Opened the solution src\ServiceStack.sln (VS 2012 version)
First I get this SQL Express Error after opening it for the first time:
Now I try to build all on the solution and I get this build error:
So tell me what I could possibly doing wrong? This is a "Release" right? It should build right? It's not rocket science so how can people say this is a "dev consumer" issue? All I want is a stable release build. Simple.
I've just upgraded ServiceStack.Examples to VS 2013/IIS Express and updated it to the latest version of ServiceStack v3.9.63 that was just deployed. It should all build now, also some examples requires redis to be running on localhost.
I have the following build target set to do my deploys, as mentioned by Hanselman in his Tiny Happy Features #3 and as also noted in many other places as what I consider to be the recommended approach:
msbuild my_web_application.csproj /p:Configuration=Production;
DeployOnBuild=true;
PublishProfile=Production;
VisualStudioVersion=11.0;
AllowUntrustedCertificate=true;
AuthType=NTLM
This does the job, and replaces the deployment step I previously had via invoking ms deploy on the command line:
msdeploy.exe" -source:package="c:\source_to_my_web_application.zip" -dest:auto,my_server_name,includeAcls="False" -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -setParamFile:"c:\source_to_my_web_application\Package.SetParameters.xml"
The biggest difference I can see in the two methods is that the command line call will only push over the files that have modifications, whereas the msbuild call sends over the entire web application every time.
Is there a way to make the msbuild version do the "sync" behavior, like the direct call to msdeploy did for me?
From what I've been able to establish, syncing from a package (like the one created for this particular MSBuild command) will find differences related to the local working copy it's trying to deploy from.
If I do a fresh checkout, then build and deploy, it'll publish the entire web application.
If I do a clean and rebuild on that working copy, it'll only publish the dlls that got rebuilt.
If I do a build on that, it'll only publish the web.config files that got transformed and some other random dlls that I can't make rhyme or reason out of.
The bottom line, I guess, is that with our CI server setup, it should be assumed that all files will be published to the server, and if it happens to publish fewer than that, it's a bandwidth bonus.
As a side note, I've also encountered random, unreliable 404 errors while doing otherwise normal ms deploy commands. They seem to be intermittent, and can vary between my own workstation, my colleagues, and the CI server so that the MS Deploy service will return a 404 or execute just fine within seconds of each successive call. Solutions I've found for this type of behavior range from restarting Visual Studio to uninstalling and reinstalling various components, and making sure you do it in the right order and only the second Tuesday of the third week of any month ending in "ary"...
The takeaway for me is that this tool is sketchy, and that if you can get a setup to work with any amount of reliability it's a miracle and you should not touch it ever again and pray to the silicon gods that it stays that way.
I have written a sequential workflow in SharePoint on our development environment. After testing, we decided to deploy this workflow as a feature on the staging environment. We did the following:
copied the strongly named assembly to the GAC using gacutil
copied feature.xml and workflow.xml to WebServerExtensions/12/templates/features/someFolder
installed feature (stsadm command)
activated feature (stsadm command)
All worked exactly as planned and the workflow behaved correctly. The problem was, we decided to change something in the code (a message was not very self explanatory), so on the development machine we updated the message as requested and rebuilt the project.
The problem is, we cannot seem to find a way to correctly get rid of the previous version of this workflow/feature.
To deploy the upgrade, we:
deactivated and uninstalled the feature (stsadm commands), removed also from GAC.
increased the version of the assembly
performed steps 1 to 4 from above.
When using the workflow we are still getting the first message, we cannot find a way to get the new message to be displayed.
What are we missing?
All the workflow logic "lives" inside the code assembly you are running. This means you can delete the old version of DLL (don't change assembly version numbers, use AssemblyFileVersion instead) from the GAC and replace it with the new version.
Be aware, though, that if you have changed the workflow in the designer, running instances of the old workflow version will "freeze" and never finish. Ask your users to finish their running WF-s before you upgrade the code.
It seems that the problem was in the Workflow.xml file.
Because I incremented the AssemblyFileVersion, and only replacing the dll in GAC did not work, I checked the two xml files: Feature and Workflow to see which one did not recognize the new dll (if the case). The workflow.xml file had a reference to the old version in it. I updated that, installed and activated the feature again, and it is working perfectly now.
Thanks for your support!